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FOREWORD 


The  primary  objective  of  this  pamphlet  is  to  provide 
laboratory-level  project  engineers  with  a systematic 
approach  for  Statement  of  Work  (SOW)  preparation.  It  was 
written  by  project  engineers  who  are  experienced  in  SOW 
writing.  The  systematic  approach  presented  should  enable 
a project  engineer  to  review  and  understand  all  factors 
that  bear  on  this  project  BEFORE  the  writing  of  a state- 
ment of  work  is  attempted.  It  facilitates  the  orderly 
identification  and  sequencing  of  project  requirements, 
tasks,  criteria,  and  milestones  in  light  of  the  project 
schedule  and  resource  constraints.  The  application  of 
the  recommended  methodology  affords  the  SOW  writers  with 
the  opportunity  to  assure  themselves  of  a thorough  and 
realistic  understanding  of  project  requirements.  Such 
an  understanding  is  prerequisite  to  the  preparation  of 
a meaningful  and  specific  SOW  which  industry,  in  turn, 
will  be  able  to  both  understand  and  accomplish. 

Statement  of  work  review  procedures  are  recoxnmended. 
to  assist  the  project  engineer  identify  and  correct  any 
gaps  between  what  he  intended  to  write  and  what  he  has 
actually  written.  The  need  and  purpose  for  format  con- 
siderations is  also  discussed.  Frequently  experienced 
pitfalls  in  SOW  content  are  presented  and  reviewed  with 
the  intention  of  helping  a project  engineer  avoid  them  in 
future  SOWs.  A chapter  on  the  legal  implications  of  the 
SOW  is  included  to  familiarize  project  engineers  with  some 
legal  rules  pertaining  to  SOW  requirements  interpretation. 
Finally,  some  recommendations  are  proposed  to  help  a 
project  engineer  assure  himself  of  the  receipt  of  quality 
technical  proposals  from  industry  that  are  truly  responsive 
to  the  requirements  of  his  statement  of  work. 

This  handbook  was  prepared  under  the  sponsorship  of 
HQ  AFSC/DL  by  the  Air  Force  Institute  of  Technology,  School 
of  Logistics  (AFIT/SLC) , Wright-Patterson  AFB,  Ohio. 

Major  Fredrick  T.  Dehner,  Director,  AFIT  Course  475,  Labora 
tory  R&D  Management,  directed  the  handbook  preparation. 
Co-authors  from  the  AFSC  Laboratories  were:  Captain 

William  G.  Cathey,  AFATL;  Captain  Edward  L.  Wallace,  AFAL; 
and  First  Lieutenant  Roger  A.  Mickish,  AFWL. 
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It  is  intended  that  this  pamphlet  complement  AFSCP 
800-6  and  other  regulatory  documentation  that  pertains  to 
SOW  preparation.  Since  there  are  a multitude  of  formally 
accepted  titles  for  the  personnel  within  the  AFSC  (DL) 
Laboratories  who  write  SOWs  and  manage  the  resulting  con- 
tractual R&D  efforts,  the  expression,  project  engineer, 
is  usod  as  a general  label  to  circumvent  the  title  problem. 
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CHAPTER  1 

THE  RESEARCH  AND  DEVELOPMENT  STATEMENT  OF  WORK 


INTRODUCTION 


On  an  annuetl  basis,  Air  Force  Systems  Command  is 
awarding  or  administering  more  than  16,000  contracts 
valued  in  excess  of  43  billion  dollars  with  more  than 
5,000  different  contractors.  The  basis  of  each  of  these 
contracts  is  a document  called  a Statement  of  Work  (SOW) 
which  identifies  what  the  contractor  is  to  accomplish  on 
behalf  of  the  product  divisions  or  laboratories  of  Air 
Force  Systems  Command.  The  specific  efforts  defined  for 
contractor  accomplishment  in  this  document  range  from 
small  basic  research  studies  to  the  acquisition  of  new 
major  weapons  systems.  The  clarity,  accuracy,  and  com- 
pleteness exhibited  in  the  SOW  content  will  determine,  to 
a large  degree,  whether  the  objectives  of  the  contract 
will,  in  fact,  be  achieved. 

DEFINITION 


Within  the  frame  of  reference  of  the  laboratories  of 
the  A£ -C  Director  of  Science  and  Technology , the  Research 
and  Development  SOW  takes  on  the  following  meaning: 

The  Research  and  Development  Statement  of  Work 
identifies  four  specific  technological  objectives: 

a.  The  requirement (s)  to  be  fulfilled. 

b.  The  reason  for  the  requirement (s) . 

c.  The  tasks  to  be  performed  to  satisfy  the 
requirement (s) . 

d„  The  points  of  responsibility  for  task 
accomplishment . 

In  Section  IV,  Special  Types  and  Methods  of  Procure- 
ment, Part  I - Procurement  of  Research  and  Development  of 
the  Armed  Forces  Procurement  Regulations,  additional  insight 
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is  provided  concerning  Research  and  Technology  Statement  of 
Work,  that  is: 

4-105  Statement  of  Work. 

(a)  The  preparation  and  use  of  a clear  and 
complete  statement  of  work  is  essential  to  sound 
contracting  for  research  and  development.  In 
research,  exploratory  development  and  advanced 
development,  statements  of  work  must  be  individu- 
ally tailored  by  technical  and  contracting  personnel 
to  attain  the  desired  degree  of  flexibility  for 
contractor  creativity,  both  in  submitting  proposals 
and  in  contract  performance.  Careful  distinction 
must  be  drawn  between  level-of-effort  work  state- 
ments, which  essentially  require  the  furnishing  of 
technical  effort  and  a report  on  the  results  thereof, 
and  task  completion  type  of  work  statements  which 
often  require  development  of  tangible  end  items 
designed  to  meet  specific  performance  characteristics. 

(b)  In  preparing  statements  of  work,  the  follow- 
ing elements  shall  be  considered: 

(i)  a general  description  of  the  required 
objectives  and  desired  results; 

(ii)  background  information  helpful  to  a 
clear  understanding  of  the  requirements  and  how 
they  evolved; 

(iii)  technical  considerations,  such  as  any 
known  specific  phenomena  or  techniques; 

(iv)  a detailed  description  of  the  technical 
requirements  and  subordinate  tasks; 

(v)  a description  of  reporting  requirements 
and  any  other  deliverable  items,  such  as  data, 
experimental  hardware,  mock-ups,  prototypes,  etc.;  and 

(vi)  other  special  considerations. 

THE  RESEARCH  AND  DEVELOPMENT  STATEMENT  OF  WORK  DILEMMA 

Research  and  Development  projects,  quite  frequently, 
are  intrinsically  uncertain  and  susceptible  to  cnange. 

The  project  engineer  preparing  an  R&D  SOW  faces  the 
demanding  challenge  of  writing  a statement  of  work  that 
is  adequate  for  the  government,  for  procurement  purposes. 
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and  for  prospective  contractors.  A fundamental  dilemma 
(see  Figure  1)  is  experienced.  The  SOW  should  be  definitive 
enough  to  protect  the  government's  interest  (return  on 
investment)  yet  flexible  and  broad  enough  to  encourage 
industry  interest  and  allow  the  contractor's  creative  effort 
,to  be  added  to  the  program  (Simulation  of  Contractor 
Scientific  Creativity) . The  project  engineer  is  responsible 
for  the  creation  and  maintenance  of  the  delicate  balance 
that  is  needed  between  these  conflicting  extremes. 

Statements*  of  work  for  research,  exploratory  or 
advanced  developments  can  widely  vary  from  simple  statements 
of  objectives  to  complex  statements  of  performance  require- 
ments. Regardless  of  their  simplicity  or  complexity,  a 
properly  planned  and  expressed  SOW  is  the  heart  of  any  R&D 
contract  with  industr; . The  success  of  any  contractor's 
effort  to  satisfy  the  requirements  of  the  contract  is 
inextricably  dependent  upon  the  capability  of  the  project 
engineer  to  generate  a clear  and  specific  SOW. 

GENERAL  PRINCIPLES  FOR  RESEARCH  AND  DEVELOPMENT  STATEMENTS 
OF  WORK 

The  following  general  principles  apply  to  all  R&D 
Statements  of  Work: 

a.  The  SOW  must  not  be  so  narrow  that  it  stifles 
the  contractor's  creative  effort  as  a result  of  government 
over-direction.  The  most  capable  and  desirable  sources 
may  be  hesitant  to  submit  proposals  in  response  to  this 
type  of  SOW.  In  addition,  if  a contract  were  awarded, 
experience  has  shown  that  supplemental  agreements  may  have 
to  be  incorporated  into  the  basic  effort  to  allow  for 
changes  precipitated  by  a subsequent  broadening  of  SOW 
constraints. 

b.  The  Government  does  not  award  contracts  for 
completely  undirected  research  and  development.  If  the 
R&D  SOW  is  written  in  too  broad  a manner,  firms  may  not 
choose  to  respond  because  of  the  risk  involved,  the 
inability  to  relate  work  requirements  to  their  talents 
ar.d  capabilities,  or  because  of  pricing  difficulties. 

While  unnecessarily  restrictive  R&D  SOWs  are  usually 
undesirable,  they  must  be  specific  in  their  descriptions 
of  desired  objectives. 
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FIGURE  1 - The  R5D  Statement  of  Work  Fundamental  Dilemma 
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c.  A contractor,  taking  his  ultimate  direction  from 
the  SOW  alone,  should  be  able  to  perform  the  required  work. 

The  objective  of  writing  a statement  of  work  is  the  achieve- 
ment of  an  agreement  and  understanding  with  a contractor 
concerning  the  specific  nature  of  the  technical  effort  to 

be  performed.  The  SOW  serves  as  the  nucleus  of  a contract, 
that  is,  an  agreement  between  competent  parties  (the  govern- 
ment and  a contractor)  for  a valid  consideration  (the 
government's  payment  of  a price  for  the  contractor's  promise 
of  performance)  to  accomplish  a lawful  purpose  with  terms 
and  conditions  clearly  and  specifically  set  forth.  The 
adequacy  of  this  contract  to  properly  represent  the  effort 
to  be  performed  is  a direct  function  of  the  quality,  clarity, 
and  completeness  of  its  statement  of  work. 

d.  The  very  nature  of  research  and  development  is  such 
that  it  may  be  difficult  to  arrive  at  a complete  understanding 
with  the  contractor  regarding  the  technical  effort  to  be 
performed.  R&D  SOWs  are  based  upon  the  known  and  usable 
portions  of  the  technological  base.  The  project  engineer 
should  search  for  and  locate  the  existing  knowledge  upon 
which  his  effort  shall  be  based.  Since  it  is  virtually 
impossible  for  one  person  to  be  the  source  of  this  knowl- 
edge, it  is  in  the  best  interests  of  the  project  engineer 

to  convene  a team  of  knowledgeable  experts  from  within  the 
government  who  can  assist  him  in  determining  the  current 
technology  base  and  in  preparing  the  statement  of  work. 

e.  Quite  frankly,  R&D  efforts  are  directed  at  tasks 
that  are  beyond  the  state-of-the-art.  Consequently,  it 
cannot  be  logically  expected  that  a contractor  shall  always 
be  able  to  accomplish  the  desired  or  sought-after  result. 
Therefore,  the  form  of  the  contract  to  be  awarded  for  R&D 
efforts  shoald  be  compatible  to  the  nature  of  the  effort 

to  be  performed.  A completion  contract  should  be  used  when 
the  contractor  will  be  required  to  complete  and  deliver  to 
the  government  a specified  end  product,  that  is,  experi- 
mental hardware,  new  methods,  demonstrations,  or  other 
tangible  results.  A level-of-effort  contract  is  more 
appropriate  for  study  and  early  development  work.  Such  a 
contract  essentially  sets  forth  the  level-of-effort  to  be 
performed  "by  the  contractor  and  its  time  period.  It 
requires  the  contractor  to  furnish  technical  or  professional 
effort  and  a report  of  the  results  of  the  effort.  A phase 
option  type  contract  divides  the  R&D  effort  into  successive 
phases  where  a given  phase  must  be  accomplished  before  the 
next  phase  is  started.  Such  a contract  is  more  manageable 
and  facilitates  the  government  identification  and  monitoring 
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of  contractor  progress.  Early  detection  of  unsatisfactory 
contractor  progress  is  additionally  permitted  by  phasing. 

It  provides  the  government  with  the  opportunity  to 
re-evaluate  and/  if  necessary,  redirect  the  effort  in  a 
timely  manner. 

f.  The  element  of  risk  inherent  in  R&D  SOWs  will 
affect  the  compensation  arrangement  of  the  contract 
written.  For  example,  for  level  of  effort  type  of  contracts, 
a firm  fixed  price  compensation  may  be  feasible.  If  the 
amount  of  contractor  effort  (performance,  time,  and  cost 
goals)  is  extremely  uncertain  at  the  outset,  then  a cost 
reimbursement  compensation  may  be  necessary  because  of  the 
inability  to  estimate  costs  with  any  reasonable  degree  of 
accuracy.  For  efforts  where  it  is  desirable  to  motivate 

and  reward  contractor  initiative  and  creativity  in  pursuit 
of  desired  objective,  incentive-type  compensations  may  be 
appropriate.  The  relationship  of  risk  inherent  in  R&D 
efforts  to  the  type  of  compensation  arrangement  selected 
for  the  contract  is  discussed  in  more  detail  in  Appendix  A. 

g.  The  SOW  not  only  affects  the  number  of  qualified 
sources  willing  and  able  to  prepare  proposals  for  the  work, 
it  also  influences  the  proposers'  approaches  to  the  R&D 
effort.  It  additionally  has  a direct  impact  on  the  govern- 
ment's evaluation  of  proposals.  Proposal  evaluation  must 
be  based  on  the  SOW,  that  is,  on  what  the  project  engineer 
and  his  SOW  preparation  team  have  stated  they  desire  the 
contractor  to  pursue. 

h.  The  SOW  impacts  on  the  administration  of  the 
contract.  It  defines  the  scope  of  the  effort,  that  is, 
what  the  contractor  does  and  what  the  government  receives. 

The  manner  in  which  the  scope  is  defined  will  govern  the 
amount  of  direction  that  project  engineers  can  give  and 
what  the  contractor  will  accept  during  the  contract's 
life.  Any  changes  in  the  scope  of  an  active  contract's 

SOW  require  formal  contract  modification  and  may  precipitate 
increased  and  possibly  unnecessary  contract  costs. 

i.  It  is  of  paramount  importance  that  project 
engineers  guide  their  SOW  writing  efforts  so  as  to  make 
more  than  one  interpretation  virtually  impossible.  This 
is  a most  demanding  communication  challenge.  The  SOW  is 
read,  interpreted,  and  acted  upon  by  government  and 
contractor  personnel  of  widely  varying  backgrounds,  that 
is,  scientists,  engineers,  functional  experts,  contracting 
officers,  buyers,  price  analysts,  negotiators,  lawyers,  and 
contract  administrators  (to  list  a few) . 
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The  project  engineer  of  an  R&D  program  is  entrusted 
with  the  responsibility  of  managing  all  aspects  of  his 
assigned  program.  Commensurate  with  that  responsibility 
is  the  expectation,  on  the  part  of  all  levels  of  project 
engineer  supervision,  that  the  R&D  effort  will  have  its 
resources  inana^  : in  an  efficient  manner.  It  is  assumed 
that  any  resui  g contractual  effort  will  be  directed 
toward  the  achi  .cement  cf  the  desired  R&D  objectives. 

This  expectation  shall  only  be  realized  if  the  project 
engineer  concerned  exercises  meticulous  care  in  the  prep- 
aration of  clear  and  comprehensive  statement  of  work  for 
the  effort.  The  project  engineer  needs  to  keep  in  mind 
that  a well-v/ritten  SOW  will  favorably  affect: 

a.  The  motivation  of  contractors  toward  quality 
proposal  preparation; 

b.  The  number  and  variety  in  approach  of  proposals 
submitted  by  industry; 

c.  The  number  of  contractor  misunderstandings  while 
they  are  writing  their  proposals; 

d ; The  evaluation  of  technical  proposals; 

e.  Improved  cost  proposals  from  industry  on  the 
R&D  effort  to  be  performed; 

f.  Contract  price  and  technical  negotiations; 

g.  The  form  and  compensation  arrangement  in  the 
awarded  contract; 

h.  Reduced  contract  costs;  and 

i.  Improved  administration  of  the  contractual  effort. 

Most  important  to  the  project  engineer  is  the  fact  that 
a well-written  statement  of  work  enhances  the  contractor's 
performance  in  pursuit  of  SOW  objectives.  Clear  SOWs  will 
permit  meaningful  communication  to  and  understanding  by  the 
contractor  of  the  technical  effort  to  be  performed. 
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TRADITIONAL  STATEMENT  OF  WORK  PREPARATION  TECHNIQUES 


Probably  no  aspect  of  the  total  R&D  procurement  process 
has  received  less  attention  than  the  preparation  of  meaning- 
ful guidelines  to  assist  project  engineers  in  determining 
HOW  to  plan,  organize,  write,  and  review  their  statement 
of  work  for  R&D  contractual  efforts.  Many  formats  are 
available  for  project  engineers  to  consider  in  the  struc- 
turing of  SOW  content.  However,  the  subject  "How  tc  Begin" 
the  development  of  SOW  content  has  received  only  scant 
attention. 

As  a result  of  this  information  void,  project  engineers 
have  written  SOWs  by  the  "trial-and-error"  method,  the 
"scissors-and-scotch  tape"  approach,  and  rarely,  by 
contractor  dictation. 

The  "trial-and-error"  method  of  SOW  preparation  is 
the  procedure  used  most  frequently  by  project  engineers. 

It  results  in  numerous  rewrites  of  the  >0W  prior  to  and 
during  negotiation  and  occasionally  necessitates  contract 
modification  after  contract  award.  The  waste  of  both 
government  and  contractor  time  and  the  high  potential  for 
incurring  unnecessary  increased  contract  costs,  schedule 
slippages,  and  deficiencies  in  technical  performance  are 
the  obvious  disadvantages  of  this  method  of  SOW  preparation. 
The  waste  can  be  compounded  if  project  engineers  persist 
in  using  this  method  on  subsequent  SOWs  without  taking  into 
consideration  the  lessons  learned  from  previous  "trial-and- 
error"  attempts.  The  best  that  can  be  hoped  for  with 
"trial-and-error"  statements  of  work  are  contractor  proposals, 
negotiations,  contracts,  and  contractor  performance  that  all 
reflect  the  "trial-and-error"  philosophy  of  the  SOW.  The 
project  engineer  cannot  afford  to  allow  this  type  of 
deficiency  to  gain  control  of  his  R&D  program. 

At  times,  a project  engineer  finds  himself  in  a 
situation  where  he  does  not  have  sufficent  time,  due  to 
organizational  deadlines,  to  write  a quality  statement  of 
work.  Under  these  circumstances,  SOWs  are  removed  from 
folders  for  projects  of  a similar  nature  and  the  project 
engineer* s "scissors-and-scotch  tape"  get  a thorough 
workout.  The  danger  of  this  approach  is  that  incoherent, 
incomplete,  inconsistent,  antiquated,  or  possibly  irrelevant 
paragraphs  get  introduced  into  a statement  of  work.  In 
some  cases,  they  elude  the  technical,  procurement,  and 
negotiation  review  process.  They  do  not  get  detected  until 
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! contractors  have  wasted  resources  trying  to  integrate  them, 

in  a meaningful  manner,  into  the  contractual  effort.  A 
project  engineer  would  never  allow  a contractor  to  utilize 
a "scissors-and-scotch  tape"  approach  in  his  fulfillment  of 
contract  requirements.  With  equal  vigor,  he  should  never 
allow  himself  to  be  forced  into  using  the  "scissors- 
and-scotch  tape"  approach  to  statement  of  work  preparation. 
Experience  has  shown  that  there  can  be  no  substitute  for  a 
thorough  and  well-written  statement  of  work. 

Contractor-prepared  statements  of  work  are  specifically 
forbidden  by  procurement  regulations.  This  prohibition  is 
based  on  sound  reasoning.  Contractor-prepared  Sows  give  an 
excessive  competitive  advantage  to  one  contractor  to  the 
detriment  of  all  other  contractors  who  might  possess  the 
capability  to  perform  the  desired  effort.  The  effect  of  this 
practice  might  be  the  refusal  of  qualified  contractors  to 
participate  in  the  development  of  certain  segments  of  the 
Defense  Department's  technological  base.  This  is  contrary 
to  the  purpose  of  all  federally  funded  research  and  develop- 
ment, that  is.  the  advancement  of  the  scientific  and 
technological  base  of  our  nation.  In  addition,  contractor 
dictated  SOWs  could  virtually  deny  the  government  prerogative 
of  the  technical  management  and  direction  of  its  R&D  contracts. 
Finally,  contractor-prepared  £OWs  can  be  protested  legally 
on  the  grounds  that  they,  in  reality,  may  deny  the  award  of 
contract  to  all  qualified  contractors  who  did  not  have  the 
advantage  of  assisting  in  the  SOW  preparation.  In  addition 
the  obvious  problems  which  this  protest  may  precipitate, 
it  is  reasonable  to  expect  that  any  resulting  procurement 
action  will  be  substantially  delayed. 

HOW  TO  BEGIN 

The  question  of  "How  to  Begin"  the  preparation  of  a 
statement  of  work  is  the  core  subject  area  of  this  pamphlet. 
Before  writing  a statement  of  work,  a project  engineer  must 
develop  a thorough  understanding  of  all  of  the  factors  that 

I will  bear  on  his  project  and  will  be  reflected  in  his  SOW. 

His  methodology  must  be  thorough,  logical  and  realistic. 
Understanding  of  the  project  must  precede  and  dictate  the 
1 documentation  and  implementation  of  the  project  and  not 

! vice  versa . 


In  order  to  assist  project  engineers  in  pursuing 
a systematic  approach  to  SOW  preparation,  the  task  of 
developing  a SOW  has  been  broken  down  into  four  distinct 
areas;  that  is,  planning,  organizing,  writing  and  format 
considerations  for  SOW  preparation.  They  are  the  subject 
of  the  next  four  chapters. 
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CHAPTER  2 


PLANNING  THE  STATEMENT  OP  WORK 


PURPOSE  OF  PLANNING  PHASE 


A statement  of  work  has  frequently  been  described  as 
a document  that  details  a strategy  for  contractor  and 
government  accomplishment  of  the  objectives  of  an  R&D 
project.  But  before  any  strategy  can  be  developed  by  a 
project  engineer,  certain  basic  questions  must  be  answered 
and  understood,  that  is, 

a.  What  are  the  objectives  of  the  project; 

b.  Where  did  the  objectives  come  from,  who  originated 
them,  and  why  were  they  originated; 

c.  What  is  the  current  status  (state-of-the-art, 
resource,  and  schedule  constraints)  for  the  effort;  and 

d.  Based  upon  current  status,  what  is  the  risk 

factor  associated  with  the  achievement  of  project  objectives? 

A project  engineer  is  expected  to  be  an  expert  on  not 
only  all  of  the  technical  factors  that  bear  on  his  project, 
but  all  of  the  background  information  which  establishes  and 
delimits  his  project.  He  cannot  effectively  manage  his 
project  if  he  concentrates  on  the  technical  factors  and  does 
not  develop  a thorough  understanding  of  the  background  infor- 
mation for  his  program.  This  chapter  recommends  a procedure 
that  will  enhance  project  engineer  understanding  of  background 
information  - the  prerequisite  to  delineation  of  tasks  and 
organization. 

PLANNING  PHASE  CHECKLIST 


Simply  stated,  the  planning  phase  of  SOW  preparation 
is  aimed  at  a thorough' investigation  of  the  why  and  what 
for  the  project.  The  following  checklist  should  assist  him 
in  this  determination: 

a.  Understand  the  origin  and  purpose  of  the  project. 
The  project  engineer  should  be  able” to  identify,  at  the 
outset,  the  relevancy  requirement  for  his  project.  Why 
should  the  Air  Force  commit  financial  and  manpower  resources 
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to  this  project?  In  what  specific  manner  does  this  project 
have  a direct  and  apparent  relationship  to  current  or  future 
AP  needs?  Who  initially  identifies  the  need?  How  and  where 
is  it  identified/  and  what  is  really  asked  for?  The  answers 
to  these  questions  can  be  found  in  the  planning  and  program- 
ming documentation  for  the  project.  Depending  on  the  nature 
of  the  project,  the  answers  may  be  found  in  a Required 
Operational  Capability  (ROC)  Document/  Technology  Need  (TN) , 
In-House  Basic  Research  documentation/  exploratory  or 
advanced  development  plans.  Project  Management  Directives, 
technology  planning  guidance  or  other  appropriate  documen- 
tation. On  existing  projects,  the  project  engineer  should 
find  the  applicable  documentation,  or  reference  thereto,  in 
the  project  folder.  For  new  efforts,  the  project  engineer's 
supervisor  or  the  laboratory  plans  and  programs  office  should 
be  able  to  identify  the  applicable  documentation. 

b.  Identification  and  Analysis  of  Current  and  Previous 
Efforts  related  to  Project.  The  purpose  of  this  investiga- 
tion  is  to  determine  previous  accomplisliments  and 

similar  efforts  that  have  a direct  bearing  on  the  project 
engineer's  program.  These  efforts  may  fall  under  the  tech- 
nical jurisdiction  of  the  project  engineer's  laboratory  or 
other  AF  or,  DOD  R&D  organizations.  In  order  to  make  this 
determination,  the  project  engineer  should  initially  use 
the  most  available  resource  at  his  disposal,  that  is,  the 
experienced  project  engineers  in  his  own  laboratory.  Then 
a Defense  Documentation  Center  literature  search  should  be 
requested  through  the  Base  Technical  Library  in  order  to 
secure  information  on  all  previous  and  current  DOD  efforts 
that  may  contribute  to  the  project  engineer's  effort.  The 
end  result  of  this  exercise  will  be  an  answer  to  the  follow- 
ing question,  that  is,  "What  is  the  current  status  of  the 
DOD  technological  base  upon  which  the  project  engineer's 
effort  will  be  built?".  The  answer  should  assist  him  in 
avoiding  any  unnecessary  duplication  of  effort. 

c . Conduct  a Literature  Search  to  Determine  Current 
"State-of-the-Art11 . There  are  numerous  professional  journals 
and  articles  that  may  not  surface  during  Step  b,  but  will 
have  a direct  impact  on  project  status  determination  and 
research  requirement  identification.  Experienced  co-workers, 
professional  colleagues,  and  technical  librarians  will  be 
invaluable  to  the  project  engineer  in  conducting  this 
search.  In.  addition,  the  laboratory  Independent  Research  and 
Development  (IP.&D)  monitor  in  the  Plans  and  Programs  Office 
may  be  of  assistance  in  identify  Lug  the  current  industry 
state-of-the-art  and  associated  IR&D  funding  levels  for 

your  project. 
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d.  Determine/Verify  the  R&D  Category  for  the  Project. 

As  a result  of  information  gained  from  Steps  a and  c,  the 
project  engineer  understands  the  nature  of  the  requirement 
and  the  status  of  the  technological  base  upon  which  his 
project  will  be  built.  He  can  now  determine  whether  his 
project  is  within,  at,  or  beyond  the  current  state-of-the- 
art  and  consequently  assess  the  technical  risk  associated 
with  his  project.  This  risk  determination  will  have  a 
definite  impact  upon  the  accomplishment  of  project  objectives 
and  the  resultant  management  scheme  that  evolves  for  the 
project. 


e.  Identify  the  resource,  schedule,  and  compensation 
arrangement  constraints  for  the  project.  Now  that  the 
project  engineer  has  specific  grasp  of  the  nature  and 
magnitude  of  his  project's  objectives,  he  should  identify 
any  schedule  and  resource  constraints  which  have  been 
assigned  to  his  project.  The  type  of  contract  to  be 
awarded  must  be  compatible  and  consistent  with  the  risk 
involved  in  the  effort.  Appendix  A may  serve  as  a useful 
guide  during  this  determination. 

f . Determine  the  existing  Statement  of  Work  Routing/ 
Coordination  Policies  and  Procedures  m the  Laboratory. 

The  project  engineer  should  thoroughly  understand  all  of 
the  requirements  of  his  laboratory's  SOW  coordination  cycle 
well  in  advance  of  the  actual  SOW  coordination.  He  should 
brief  all  elements  in  the  cycle  on  the  nature  of  his  project 
and  solicit  their  assistance  with  respect  to  specific  SOW 
preparation  guidelines.  The  pre-coordination  will  minimize 
the  number  and  extent  of  SOW  rewrites  required  during  the 
final  coordination  cycle. 

g . Identify  all  military  specifications/standards  and 
other  relevant  documentation  applicable  to  the  project.  The 
project  engineer  should  consult  with  all  of  the  laboratory 
functional  experts  who  represent  disciplines  that  will  have 
impact  on  his  effort.  An  early  identification  of  this  impact 
will  permit  a timely  and  integrated  incorporation  of  relevant 
documentation  into  the  task  descriptions  of  the  SOW. 

SUMMARY 

As  a resul c of  the  foregoing  analysis  of  the  background 
information  on  his  project,  the  project  engineer  is  able  to 
direct  his  attention  to  the  tasks  that  need  to  be  accomplished 
in  pursuit  of  project  objectives.  He  now  possesses  an 
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understanding  of  the  origin  and  reason  for  his  project, 
the  state-of-the-art  upon  which  his  effort  will  be  based, 
the  constraints  that  have  been  placed  on  his  project,  the 
amount  of  risk  involved  in  his  effort,  and  the  SOW  coor- 
dination cycle  and  functional  discipline  requirements 
that  will  have  to  be  incorporated  into  his  SOW  preparation 
efforts.  He  is  now  ready  to  enter  the  organizing  phase 
of  SOW  preparation,  the  subject  matter  for  the  next  chapter. 
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CHAPTER  3 


ORGANIZING  THE  STATEMENT  OF  WORK 


PURPOSE  OF  ORGANIZING  PHASE 


Proper  organization  of  the  technical  effort  is  a 
mandatory  prerequisite  to  the  preparation  and  use  of  a 
clear  and  complete  research  and  development  statement  of 
work.  One  of  the  best  ways  that  a project  engineer  can 
assure  himself  of  a complete,  orderly,  and  integrated 
SOW  is  by  the  preparation  of  an  outline  which  will 
structure  and  sequence  the  technical  effort  and  all  its 
interdependencies.  A good  technical  effort  outline  will: 

a.  Aid  in  the  analysis  of  the  project  engineer's 
ideas  concerning  the  R&D  requirement (s) ; 

b.  Aid  in  organizing  the  description  of  the  technical 
requirement (s)  and  provide  smoothness  and  continuity; 

c.  Help  avoid  significant  omissions; 

d.  Help  eliminate  unnecessary  and  duplicative  tasks 
in  the  efforts;  and 

e.  Allow  the  project  engineer  to  focus  his  complete 
attention  toward  the  effort  for  which  he  will  prepare  a 
statement  of  work. 

ORGANIZING  PHASE  CONSIDERATIONS 


In  preparing  the  outline  of  the  technical  effort, 
the  project  engineer  should  direct  his  primary  attention 
to  a precise  statement  of  project  objectives,  the  tasks  to 
be  performed  in  pursuit  of  those  objectives,  the  identifi- 
cation of  task  sequencing  and  interrelationships  (phasing, 
if  appropriate)  and  the  specific  areas  for  required  contractor 
effort.  Depending  upon  the  nature  of  the  R&D  effort,  the 
risk  involved^  and  any  internal  laboratory  and  procurement 
programs  and  procedures,  the  following  efforts  should  be 
considered  and,  whenever  appropriate,  included  in  the 
outline: 


a.  Specifically  identify  the  desired  end  objectives 
(product  or  service)  of  the  project  and  its"  associated 
technical  requirements , that  is,  (technical  goals,  design 
parameters,  performance  characteristics,  test  criteria,  etc.). 
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b.  List  background  information  that  will  aid  in  a 
clear  contractor  understanding  of  the  nature  and  origin 
of  the  R&D  requirements.  If  appropriate,  relate  the 
project  to  the  major  program  and  its  goals. 

c.  Establish  the  scope  or  limits  of  the  contractor's 
effort  in  support  of  project  objectives.  Clarity  of 
expression  is  essential  here.  Any  subsequent  effort  by  the 
contractor  beyond  this  scope  will  necessitate  changes  and 
require  new  negotiations  of  cost,  fee  and  schedule.  In 
addition,  clarity  in  the  scope  of  the  effort  is  the  basis 
for  subsequent  measurement  of  contractual  changes  and 
progress . 


d.  Delineate  technical  considerations  (that  is,  known 
phenomena,  methodology,  previous  efforts,  or  interface 
requirements  with  other  projects)  which  may  influence  the 
contractor's  technical  approach  or  efforts. 

e . List  the  specific  tasks  and  subtasks  to  be 
accomplished ~5y  the  contractor  to  satisfy  the  desired  end 
objectives  of  the  effort,  that  is,  the  contractor  effort 
to  be  accomplished  to  satisfy  technical  requirements. 

f . Sequence  the  tasks  in  the  order  of  accomplishment. 

Identify  and  exhibit  m this  sequencing  all  task  interdependencies. 

g.  Establish  relevant  parameters  for  contractor 
performance  measurement.  These  parameters  will  serve  the 
following  purposes:  (IT  contractor  adherence  to  pertinent 
contractual  efforts,  (2)  measurement  of  the  completed 
contract  results,  (3)  definition  assistance  with  respect 
to  the  relationship  of  subsequent  changes  and  redirection 
of  effort  to  the  defined  scope  of  the  effort,  and  (4) 
project  engineer  and  contracting  officer  monitoring  of 
contractor  progress.  The  Government's  and  contractor's 
ability  to  assess  the  contractor's  effectiveness  in 
satisfying  contractual  terms  is  directly  dependent  upon 
the  SOW  identification  of  measurable  schedule,  cost,  and 
technical  performance  goals. 

h.  Establish  milestones  or  government  management 
control  points  in  the  task  sequencing  where  government 
review/approval  or  acceptance/rejection  actions  are  to 
BeTTntroduced . These  controls  are  vitally  important  for 
incorporation  into  the  SOW  content  at  the  end  of  all  tasks 
which  require  a government  decision  before  the  contractor 
proceeds  to  the  next  SOW  task.  They  are  particularly 
applicable  for  phase  type  contracts  where  it  is  necessary 
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to  detect  unsatisfactory  contractor  performance  at  an 
early  stage.  It  will  allow  a project  engineer  to  inform 
procurement  personnel  of  unpromising  contractor  actions 
which  should  be  terminated  before  their  effect  compromises 
the  entire  R&D  effort. 

i.  Identify  the  management  information  requirements 
which  the  contractor  must  satisfy  xn  order  to  assure  con- 
tractor  feedback  in  support  of  project  progress  determina- 
tions by  the  project  engineer  against  the  established 
milestones  and  associated  performance  measurement  criteria. 

j . Identify  all  government  and  contractor  participa- 
tion needed  for  the  project  and  the  extent  and  nature  of 
their  task  responsibilities.  All  tasks  requiring  govern- 
ment support  ^government  furnished  equipment,  materials, 
facilities  and  extra-laboratory  government  agency  assistance) 
prior  to  contract  initiation  and  accomplishment  of  tasks 
should  be  specifically  stated.  The  nature  of  the  government 
support  to  be  provided  should  be  specifically  presented. 

k . Certify  that  the  tasks  identified  and  their 
sequencing  and  interrelationships  support  the  technical 
requirements . 

l.  Generate  a schedule  for  the  sequence  of  tasks  to 
be  performed  by  the  contractor. 

m.  Precisely  identify  contractor  delivery  require- 
ments and  dates . Include  details  about  the  type  and 
quantity  of  all  deliverable  (for  instance,  prototypes, 
theoretical  models,  breadboard  models,  mockups,  computer 
software,  drawings,  documentation,  reports  or  other  data) . 

n.  Specifically  identify  all  technical  data  require- 
ments . Include  the  intended  use  for  the  data  by  the  project 
engineer . 


o.  Identify  any  other  specific  considerations  based 
upon  the  nature  of  the  required  R&D  effort  (contractor 
derivation  of  theoretical  models  and  equations , validation 
of  statistical  sampling  techniques,  etc.). 

p.  Estimate,  when  allowed,  the  professional  and  tech- 
nical man-hours,  man-months,  man-years,  etc.,  required  to 
perform  the  R&D  effort  by  the  contractor.  This  information 
will  "provide  a common  basis  for  realistic  proposals  and 
meaningful  technical  and  price  analyses  of  the  resultant 
proposals. 
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THE  STATEMENT  OF  WORK  OUTLINE  VERSUS  THE  PROJECT  CONSTRAINTS 


After  a project  engineer  has  prepared  a detailed  outline 
of  his  R&D  project  requirements/  he  needs  to  assess  the  impact 
of  the  real-world  resource,  schedule,  and  contract  type  (com- 
pensation arrangement)  constraints  that  have  been  prescribed 
for  his  project.  A determination  must  be  made  as  to  their 
compatibility  with  the  nature  of  the  R&D  project  (the  risk 
involved  and  the  outline  of  tasks  that  has  just  been  developed 
for  his  project).  This  can  best  be  illustrated  by  Figure  2. 


Type  of 
Contract 


FIGURE  2 - The  R&D  Project  Tetrahedron 

The  amount  of  an  R&D  project  that  can  realistically  be 
performed  may,  by  analogy,  be  perceived  as  being  restricted 
within  the  interior  of  a tetrahedron  whose  vertices  repre- 
sent the  project  constraints  and  the  technical  risk  associated 
with  the  project.  After  the  project  engineer  has  developed 
the  detailed  outline  of  tasks  for  his  project,  he  must  deter- 
mine whether  his  project,  as  tasked,  will  fall  within  a 
complex  interrelationship  of  constraints.  A thorough  under- 
standing will  be  required  concerning  the  nature  of  these 
constraints,  their  interrelationships,  and  the  impact  of 
trade-offs  between  these  constraints.  In  addition,  the  project 
engineer  needs  to  develop  an  in-depth  appreciation  of  the 
consequences  associated  with  constraint  trade-offs  and  their 
effect  on  the  accomplishment  of  overall  project  objectives. 
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When  the  project/  as  outlined,  cannot  be  accomplished 
within  the  schedule  and  resource  constraints  assigned  to 
the  project,  the  project  engineer  may  need  to  eliminate, 
combine,  or  resequence  tasks  to  accommodate  the  constraints. 
Alternatively,  he  may  pursue  constraint  broadening  to  per- 
mit project  accomplishment  as  planned  and  organized.  The 
detailed  project  understanding  and  task  sequencing  accom- 
plished by  the  project  engineer  as  a result  of  following 
the  guidance  provided  in  Chapters  2 and  3 of  this  handbook 
may  allow  him  to  establish  a creditable  justification  for 
project  constraint  broadening.  In  many  instances,  the 
final  solution  to  the  problem  of  insufficient  resources 
and  schedule  for  an  R&D  project  may  be  a compromise  position. 
Tasks  are  eliminated,  combined,  or  resequenced  concurrent 
with  a broadening  of  project  constraints.  Once  the  problem 
has  been  resolved,  the  project  engineer  should  reassess  the 
technical  risk  associated  with  his  project.  He  will  then 
need  to  identify  a type  of  contract  compensation  arrangement 
that  fairly  and  reasonably  distributes  project  responsibility/ 
risk  sharing  between  the  government  and  industry  for  the 
technical  effort  to  be  performed. 

CHALLENGE  ALL  STATEMENT  OF  WORK  REQUIREMENTS 

In  addition  to  resolving  any  conflict  between  project 
constraints  and  the  project  detailed  outline,  a project 
engineer  should  objectively  challenge  all  aspects  and  tasks 
in  his  project  prior  to  the  writing  of  a statement  of  work. 

The  following  questions  may  prove  helpful  in  this  analysis: 

a.  Why  is  the  task  needed  in  the  project? 

b.  Does  it  contribute  tangible  utility  to  the  project? 

c.  How  much  does  the  task  cost  in  terms  of  the  technical 
effort  to  be  performed? 

d.  Is  the  value  of  the  task  to  the  project  worth  the 
associated  cost? 

e.  Is  there  another  way  to  accomplish  the  task?  Has 
it  been  evaluated? 

f.  What  is  the  impact  on  the  overall  project  if  the 
task  is  deleted  from  the  project? 


The  project  engineer  is  the  only  person  qualified  to 
answer  these  questions  directed  at  his  project.  It  is 
time  well  spent  if  the  project  engineer  has  answers  for 
these  questions  BEFORE  they  are  asked  during  a project 
review  or  the  SOW  coordination  cycle. 

SUMMARY 

The  thorough  organization  of  a detailed  outline 
provides  the  project  engineer  with  the  list  and  sequencing 
of  the  tasks  which  the  contractor  is  to  do  and  those  tasks 
which  the  government  must  perform  or  support.  It  provides 
him  with  an  opportunity  to  enumerate  and  study  his  concept 
before  commencing  the  actual  writing  of  the  SOW.  Incon- 
sistencies, gaps,  interrelationships  among  concepts, 
relationship  to  objectives  and  logical  organizing  are  more 
visible  to  the  project  engineer  when  he  prepares  his  SOW 
from  a detailed  outline.  Such  a practice  avoids  unnec- 
essary changes,  insertions,  and  deletions.  Finally,  a 
detailed  SOW  outline  permits  the  writer  to  concentrate  on 
the  development  of  one  idea  at  a time  since  decisions  on 
total  content  and  task  sequencing  have  already  been  made. 

As  a result  of  the  organizing  phase  of  SOW  prepara- 
tion, the  project  engineer  has  a detailed  understanding  of 
project  requirements  ’nd  the  effort  that  can  be  accomplished 
within  project  constraints.  Because  of  his  objective 
challenge  of  project  requirements  and  tasks,  he  can  provide 
a justification  for  all  of  his  project  tasks  and  can  provide 
a creditable  argument  for  project  constraint  broadening.  He 
is  now  in  a position  to  write  a clear  and  precise  statement 
of  work. 
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CHAPTER  4 

WRITING  THE  STATEMENT  OF  WORK 


INTRODUCTION 

As  a result  of  a thorough  planning  and  organizing 
of  the  R&D  effort/  the  project  engineer  knows  exactly 
the  details  and  tasks  that  need  to  be  included  in  the 
Statement  of  Work.  Now  he  must  address  the  task  of 
documenting  in  a meaningful  and  coherent  manner  all  of 
the  requirements  and  tasks  for  the  project.  There  is 
a world  of  difference  between  the  project  engineer's 
knowledge  of  what  has  to  be  documented  and  the  actual 
documentation  thereof.  Will  he  be  able  to  write  what 
he  means  and  mean  what  he  writes  in  his  statement  of 
work?  Will  all  potential  contractors  possess  the  same 
understanding  of  project  requirements  as  the  project 
engineer? 

HOW  TO  TRANSITION  INTO  THE  WRITING  PHASE 

It  is  not  an  easy  task  for  a project  engineer  to 
write  a quality  statement  of  work.  As  was  discussed  in 
Chapter  1,  the  statement  of  work  must  maintain  a delicate 
balance  between  protection  of  the  government's  return  on 
investment  and  the  simulation  of  contractor  creativity 
during  both  proposal  preparation  and  contract  performance. 

In  addition,  the  SOW  must  be  read  and  understood  by 
government  and  contractor  personnel  of  widely  varying 
expertise.  Finally,  the  SOW  must  be  specifically  tailored 
to  the  nature  of  the  R&D  effort  to  be  performed.  As  a 
result,  it  can  be  logically  concluded  that  the  task  of 
preparing  a quality  statement  of  work  may  exceed  the 
talents  of  the  individual  assigned  management  responsibility 
for  the  R&D  effort,  namely,  the  project  engineer. 

With  these  points  in  mind,  the  project  engineer  must 
determine  what  will  transform  his  plan  and  detailed  outline 
into  a successful  R&D  project  before  he  starts  to  document 
it.  The  following  points  may  assist  him  in  making  this 
determination : 

a.  Review  the  SOW  for  the  successful  R&D  efforts  in 
his  laboratory.  It  cannot  be  assumed  that  successful  R&D 
efforts  always  contain  quality  statements  of  work.  However, 
the  chances  are  exceptionally  small  that  a poor  statement 
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of  work  resulted  in  a successful  R&D  project.  Consequently, 
by  reviewing  these  SOWs  a relationship  may  appear  between 
the  way  an  SOW  requirement  was  written  and  the  contractor's 
accomplishment  of  the  requirement.  In  some  instances,  out- 
standing contractor  performance  may  be  found  in  spite  of  the 
way  in  which  the  SOW  v?as  written.  This  detection  may  enable 
a project  engineer  to  realize  the  way  the  SOW  requirement 
should  have  been  written.  He  may  be  able  to  use  all  of 
these  findings  in  the  preparation  of  his  own  statement  of 
work. 


b.  Consult  with  project  engineers  experienced  in  SOW 
preparation.  As  was  described  earlier,  one  of  the  tradi- 
tional SOW  preparation  techniques  is  the  "trial-and-error" 
technique.  Fellow  engineers  may  be  invaluable  in  the 
identification  of  the  problems  they  have  experienced  in 
writing  a SOW.  If  a project  engineer  can  detect  the  basis 
of  their  "trials"  and  the  nature  of  the  resultant  "error," 
he  may  be  able  to  preclude  the  same  mistake  from  being 
incorporated  into  his  SOW. 

c.  Review  the  procurement  and  technical  coordination 
channels  and  procedures']!  Although  project  engineers  fre- 
quently take  a dim  view  of  these  channels  and  procedures, 
there  are  numerous  excellent  reasons  for  their  existence. 

An  open-minded  attitude  toward  them  on  the  part  of  the 
project  engineer  may  substantially  improve  his  chances  for 
a quality  SOW.  First  of  all,  although  a project  engineer 
is  singularly  responsible  for  the  management  of  all  aspects 
of  his  project,  he  cannot  be  a knowledgeable  expert  on  all 
of  these  aspects.  He  must  seek  out  and  utilize  the  guidance 
of  all  of  the  functional  experts  that  have  a concern  and 
interest  in  his  program.  Secondly,  the  functional  disci- 
plines required  in  his  project  must  be  specifically  tailored 
to  the  overall  effort.  The  only  way  in  which  this  perspective 
can  be  efficiently  introduced  into  a statement  of  work  is  by 

a close  working  relationship  between  the  project  engineer 
and  the  functional  experts. 

d.  Review  the  SOW  format  requirements  contained  in 
AFSC  and  other  laboratory  or  local  procurement  regulations. 
Although  the  subject  of  format  will  be  presented  in  detail 
in  the  next  chapter,  a project  engineer  is  well  advised  to 
be  familiar  with  this  format  while  he  is  finalizing  his 
organization  of  ideas  prior  to  writing  the  SOW. 


e.  Avoid  the  “Pride  of  Authorship”  syndrome.  This  word 
of  advice  is  easy  to  give,  but  at  tiroes  exceptionally  difficult 
to  follow.  Quite  frequently/  the  writing  of  an  SOW  can  realis- 
tically be  described  as  a long,  drawn  out  battle.  Statement 
of  work  preparation  is  quite  a time  consuming  process  in  which 
a project  engineer  has  a deep  psychological  involvement.  He 
is  the  acknowledged  expert  in  the  laboratory  for  the  technical 
subject  matter  of  the  SOW.  However,  at  times,  he  may  prema- 
turely judge  the  advice  of  technical  or  procurement  personnel 
as  being  the  input  of  "meddlers"  who  are  not  accountable  for 
the  impact  cf  their  advice  on  the  project  goals.  In  addition, 
the  time  delays  precipitated  by  rewrite  instructions  from  these 
personnel  are  considered  to  be  exorbitantly  long.  Such  an 
attitude  is  symptomatic  of  a complex  problem  in  the  SOW 
preparation  and  coordination  process.  It  warrants  further 
discussion. 

If  the  author  of  a statement  of  work  waits  until  he  has 
written  the  document  before  he  coordinates  it  with  procurement 
and  laboratory  personnel,  it  should  be  logically  expected  that 
he  will  be  sent  back,  on  numerous  occasions,  to  revise  his  SOW. 
The  resulting  frustration  and  annoyance  of  the  project  engineer 
is  understandable  but,  unfortunately,  he  brought  it  upon  him- 
self! Does  a project  engineer  belong  writing  unilateral 
technical  requirements  into  his  SOW  for  areas  in  which,  he  may 
have  no  technical  expertise?  More  important,  what  are  the 
consequences  that  can  impact  on  his  project  if  he  persists 
with  such  a practice?  It  could  very  well  be  in  the  best 
interests  of  his  project  that  he  make  the  changes  toward  which 
he  may  be  opposed  to.  Consequently,  all  recommended  changes 
must  be  reviewed  objectively  by  the  project  engineer.  He  must 
be  ready  and  willing  to  rewrite  his  entire  SOW,  if  necessary. 
Hard  writing,  coupled  with  appropriate  rewriting,  is  the  only 
way  to  assure  an  SOW  that  can  be  easily  read  and  understood 
by  potential  contractors.  There  have  been  a number  of  quality 
statements  of  work  written  by  project  engineers;  but,  more 
frequently,  weak  statements  of  work  get  prepared.  No  one  has 
ever  written  a perfect  statement  of  work!  Consequently,  the 
point  made  in  paragraph  c above  should  be  seriously  pursued 
by  a project  engineer  it  he  wants  to  minimize  the  number  of 
rewrites  that  may  be  required  for  his  SOW  before  it  is 
transmitted  to  industry  for  proposal  preparation. 


GENERAL  CONSIDERATIONS  FOR  STATEMENT  OF  WORK  WRITING 


The  task  of  writing  a quality  statement  of  work  exhibits 
the  same  problems  for  a project  engineer  as  the  writing  of  a 
graduate  thesis,  doctoral  dissertation,  technical  report,  or 
an  article  for  a professional  journal.  General  faults  which 
are  frequently  found  in  any  of  these  documents  are  long 
sentences  and  paragraphs;  abstract,  vague  or  ambiguous 
terminology;  and  excessive  or  irrelevant  material. 

The  R&D  statement  of  work  must  be  written  with  the  purpose 
of  clearly,  concisely,  and  thoroughly  defining  all  of  the 
obligations  of  the  contracting  parties  with  respect  to  the 
technical  effort  to  be  performed.  The  language  contained 
therein  should  be  consistent  in  terminology  application  and 
free  from  redundancy  and  ambiguity. 

The  requirement  that  the  SOW  be  complete  in  all  details 
is  a prerequisite  to  the  contractor's  understanding  of  the 
intent  of  the  program.  Incomplete  SOWs  may  precipitate 
contractor  refusals  to  submit  proposals.  In  addition,  they 
may  force  contractors  to  guess  the  intent  of  the  program. 

This  may  result  in  a delay  in  contract  negotiations  while  the 
SOW  is  rewritten  properly.  In  rare  instances,  R&D  projects 
have  been  terminated  due  to  an  overall  industry  lack  of  under- 
standing and  responsiveness  to  incomplete  SOWs.  Consequently, 
a very  appropriate  question  for  a project  engineer  to  ask 
while  he  is  writing  his  SOW  is  "Will  the  prospective  contractors 
be  able  to  understand  the  requirements  of  the  SOW?"  . 

Upon  receipt  of  a Request  for  Proposal  (RFP) , contractors 
carefully  evaluate  the  advantages  and  disadvantages  of  proposal 
evaluation  before  they  decide  to  submit  a proposal.  It  costs 
a company  thousands  of  dollars  if  they  commit  resources  to 
preparing  a proposal.  The  extent  of  the  balance  between  the 
talents  in  the  contractor  organization  and  the  value  of  the 
R&D  effort  to  its  overall  organizational  goals  are  carefully 
studied.  The  contractor's  ability  to  interpret  and  understand 
the  SOW  requirements  will  be  the  ultimate  basis  of  his  proposal 
decision.  As  a result,  if  more  than  one  interpretation  of  SOW 
requirements  is  possible,  it  is  logical  to  expect  the  contractor 
to  select  the  interpretation  that  is  the  most  favorable  to  his 
company.  Unfortunately,  the  contractor's  interpretation  of  the 
SOW  and  the  intended  government  meaning  are  not  always  the  same. 
For  this  reason,  project  engineers  are  advised  to  write  their 
SOWs  in  such  a manner  as  to  make  more  than  one  interpretation 
impossible. 
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There  is  a natural  tendency  for  writers  to  expand  or 
contract  their  sentence  or  paragraph  length  as  a function 
of  the  complexity  of  the  idea  to  be  expressed.  Complex 
ideas  may  force  SOW  writers  into  unnecessarily  long  state- 
ments of  requirements.  As  a result,  the  readability  and 
understandability  of  the  idea  expressed  may  be  compromised. 
Project  engineers  should  make  a deliberate  effort  to  avoid 
this  problem  in  their  SOWs.  Keep  sentences  and  paragraphs 
as  short  as  possible.  A well  planned  arrangement  of  ideas 
within  sentences  will  additionally  minimize  the  necessity  of 
excessive  punctuation. 

When  documenting  technical  or  performance  requirements 
in  a statement  of  work,  it  is  highly  desirable  to  use  conven- 
tional language  to  the  maximum  extent  practical  under  the 
circumstances.  The  intent  is  not  to  completely  eliminate 
technical  language.  The  language  used  should  be  reduced  to 
the  essentials  required  for  requirement/task  description. 
Excessive  technical  verbiage  may  obscure  the  real  require- 
ment. In  addition,  it  may  affect  the  number  of  good  sources 
willing  and  able  to  respond  with  proposals. 

Abstract  language  should  be  avoided  in  preparing  the 
statement  of  work.  The  use  of  such  words  will  all  but 
guarantee  differences  of  opinion  between  the  contractor  and 
government  With  regard  to  what  was  intended  in  the  SOW.  The 
competitive  nature  of  the  resulting  technical  proposals  may 
be  effectively  precluded  by  the  use  of  abstract  terminology. 
Furthermore,  such  terminology  will,  most  probably,  generate 
numerous  misunderstandings  during  the  life  of  the  contract. 

All  provisions  documented  in  the  statement  of  work 
should  directly  contribute  to  the  accomplishment  of  the  R&D 
project.  Irrelevant  requirements  should  be  deleted  because 
they  unnecessarily  contribute  to  the  cost  of  the  effort. 

"Nice  to  Have"  or  "Job  Security"  type  requirements  should 
be  removed  from  the  list  of  mandatory  requirements.  When  in 
doubt  concerning  the  relevancy  of  certain  requirements,  the 
following  questions  should  be  asked  and  answered  to  the 
satisfaction  of  the  project  engineer: 

a.  Does  the  requirement  specifically  tell  the  contractor 
the  task  to  be  accomplished? 

b.  Is  the  requirement  necessary  for  the  contractor  to 
determine  the  task  to  be  accomplished? 
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While  the  R&D  statement  of  work  is  expressed  in  scientific 
or  technical  terms,  it  is  also  subject  to  the  rules  of  contract 
law.  The  SOW  is  the  heart  of  the  contract  awarded  to  the 
winning  contractor.  As  a result,  it  is  subject  to  all  the  rules 
of  contract  drafting  and  interpretation  (Chapter  8 will  discuss 
this  subject  in  greater  detail) . If  the  nature  of  the  effort 
and  the  language  of  the  SOW  are  not  understood,  there  will  be 
more  areas  for  misinterpretation  in  the  SOW  than  in  the  rest 
of  the  contract.  Since  the  rest  of  the  contract  supports  the 
SOW,  the  whole  contract  may  become  a meaningless  and  argumentative 
package. 

Mandatory  language  should  always  be  used  in  the  SOW  for 
those  requirements  where  contractor  compliance  or  performance 
is  binding.  If  background  information  or  "reason  for  the 
project"  type  information  is  to  be  communicated  to  the  con- 
tractor, the  project  engineer  should  make  sure  that  this 
information  is  segrated  from  the  mandatory  requirements.  The 
structure  of  the  SOW  should  allow  a prompt  and  easy  contractor 
differentiation  between  why  the  project  was  originated  and 
what  it  will  entail  in  the  way  of  contractor  performance. 

Redundant  requirements  should  be  avoided  in  writing  a 
statement  of  work.  The  only  contribution  they  add  to  a SOW 
is  verbosity  and  a possible  decrease  of  contractor  under- 
standing of  project  requirements.  As  an  example,  repetition 
for  emphasis  serves  a valid  purpose  in  an  instructional 
document.  However,  it -serves  no  purpose  in  a statement  of 
work. 

Regardless  of  any  communication  (both  oral  and  written) 
that  takes  place  between  the  contractor  and  the  government 
during  the  R&D  contractual  effort,  the  SOW  will  be  viewed  by 
the  contractor  as  his  "Bill  of  Rights."  This  is  the  most 
important  point:  for  a project  engineer  to  remember  as  he 
sets  out  to  write  his  SOW.  A project  engineer  should  never 
be  surprised  when  hiqr  contractor  proceeds  to  perform  in 
accordance  with  the  "letter"  of  the  statement  of  work. 


LANGUAGE  OF  THE  STATEMENT  OF  WORK 

The  subject  of  the  language  to  be  used  in  a statement 
of  work  cannot  possibly  receive  sufficient  emphasis  in  this 
handbook.  An  ill-chosen  word  or  phrase  in  a SOW  can  literally 
destroy  any  chance  for  a meaningful  completion  of  project 
objectives.  There  have  been  too  many  instances  where 
semantics  has  ruined  a project  engineer’s  contractual  effort 
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to  dismiss  SOW  language  as  obvious  or  trivial.  The 
following  three  subsections  will  present  some  SOW  language 
guidelines  for  project  engineer  consideration. 

a.  Basic  Language  Guidelines 

A project  engineer  shouJ d focus  his  attention  on  the 
overall  meaning  of  words  used  in  his  statement  of  work 
rather  than  directing  a fragmented  concern  for  individual 
words,  paragraphs f or  sentences.  Words  and  phrases  must 
be  combined  with  caution  in  order  to  assure  a clear  and 
specific  SOW  content.  When  examples  are  used  in  the  body 
of  the  SOW  to  illustrate  a technical  requirement/task, 
they  should  be  specifically  labeled  as  examples  not 
contractually  binding  on  the  contractor. 

Words  should  be  used  in  a consistent  manner  through- 
out the  SOW.  The  .same  words  or  phrases  should  be  used  to 
convey  the  same  meaning.  If  a project  engineer  varies 
the  words  selected  to  express  the  same  meaning,  the  con- 
tractor reading  the  SOW  may  look  for  new  meanings  for  the 
words.  The  net  result  may  be  ambiguity  or  contradiction 
in  the  technical  requirements  of  the  SOW. 

There  are  certain  words  in  our  language  that  are 
highly  susceptible  to  misinterpretation.  Many  words  have 
potential  double  meanings.  The  word  "including"  may  mean 
"consisting  of"  or  "consisting  of  but  not  limited  to." 

Other  words  with  the  built-in  tendency  for  misinterpretation 
are  "similar,"  "type,"  "average,"  and  "about."  If  words  of 
this  nature  must  be  used  in  an  SOW,  the  project  engineer 
should  exactly  define  the  term.  There  are  many  other  words 
in  our  language  that  fit  this  category.  A project  engineer 
should  develop  a list  of  these  words  as  he  runs  into  them. 
Then  he  will  be  able  to  either  avoid  or  specifically  use 
them  in  future  efforts. 

Our  language  also  possesses  a good  number  of  vague  or 
abstract  words.  A small  sample  of  such  words  are  "character- 
istics," "concept,"  "functional,"  "implement,"  "supplement," 
and  "greatly  - Words  of  this  nature  should  be  avoided  in 
technical  writing. 

Technical  requirements  which  essentially  constitute  an 
"agreement  to  agree"  at  some  future  date  on  a particular 
aspect  of  the  statement  of  work,  can  precipitate  contractor 
misunderstandings  or  problems.  Such  requirements  should  not 


-27- 


be  included  in  the  statement  of  work.  They  cannot  be 
realistically  priced  out  in  the  contractor's  cost  pro- 
posal. The  project  engineer  cannot  assign  cost  and 
schedule  constraints  against  accomplishment  of  such 
requirements.  In  addition,  their  actual  specification 
and  negotiation  subsequent  to  contract  administration 
problems  which  can  compromise  the  completion  of  the 
project. 

In  those  cases  where  a technical  requirement 
cannot  be  appropriately  described  by  words,  an  illus- 
tration may  more  quickly  and  accurately  portray  what 
the  project  engineer  really  intends.  . However,  illus- 
trations should  only  be  used  when  they  make  a definite 
contribution  to  the  contractor's  understanding  of  the 
requirement . 

b.  Statement  of  Work  Phrasing 

There  are  certain  phrases  frequently  used  in  SOWs 
to  indicate  requirements  in  accordance  with  existing 
specifications,  drawings,  methods,  etc.  Requirements 
by  reference  should  be  written  using  standardization 
expressions  similar  to  the  following  "in  accordance 
with  Specification  (or  Standard) ...  " "shall  be  as 
specified  in  Specification....”  or  "shall  be  painted 
with  one  coat  of  paint  conforming  to  Specification..."  . 

When  necessary  to  use  the  phrase  "unless  otherwise 
specified"  to  indicate  an  alternate  course  of  action, 
the  phrase  should  always  come  at  beginning  of  paragraph. 
However,  this  phrase  should  be  limited  in  its  application. 

When  making  reference  to  a requirement  in  the  SOW 
and  the  requirement  reference  is  rather  obvious  or  not 
difficult  to  locate,  the  single  phrase  "as  specified 
herein"  is  sufficient. 

The  phrase  "to  determine  compliance  with  ..."  or 
"to  determine  conformance  to  ..."  should  be  used  in  place 
of  "to  determine  compliance  to  . . . ".  In  any  case,  use  the 
same  wording  throughout. 

In  stating  positive  limitations,  the  phrasing  will 
be  stated  as:  "The  diameter  shall  be  not  greater  than..." 

In  addition,  if  a lower  limit  specification  is  appropriate 
it  should  also  be  positively  stated. 
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The  emphatic  form  of  the  verb  shall  be  used  throughout 
the  SOW,  that  is,  in  the  requirement  section  state  "The 
indicator  shall  be  designed  to  indicate..."  and  in  the 
section  containing  test  provision  "The  indicator  shall  be 
turned  to  zero  and  220  volts  alternating  current  voltage 
applied."  For  specific  test  procedures,  the  imperative 
form  may  be  used  provided  the  entire  method  is  preceded 
by  "The  following  tests  shall  be  performed"  or  related 
wording,  thus,  "Turn  the  indicator  to  zero  and  apply  220 
volts  alternating  current  voltage. " 

The  phrase,  "The  contractor  shall  take  into  consid- 
eration...." should  not  be  utilized  for  mandatory  technical 
requirements.  There  is  no  way  a project  engineer  can 
measure  or  evaluate  contractor  performance  against  the 
requirement  to  "take  into  consideration." 

The  phrase  "shall  include  but  not  be  limited  to  the 
following...."  is  an  open-ended  SOW  requirement.  It  is 
occassionally  introduced  by  project  engineers  who  might 
not  be  willing  or  able  to  specifically  identify  all  of 
the  tasks  that  need  to  be  performed.  It  may  also  be  used 
by  the  project  engineer  in  an  attempt  to  give  the  contractor 
some  flexibility  in  requirement  satisfaction.  The  phrase 
may  precipitate  a contract  administration  nightmare  for 
any  type  of  compensation  arrangement  contract.  For  cost 
type  contract,  in  particular,  this  phrase  may  contribute 
significantly  to  cost  overruns. 

c.  Statement  of  Work  Caution  Words 

Some  everyday  words  can  be  very  troublesome  in  the 
field  of  procurement.  The  following  subparagraphs  list 
some  of  those  most  commonly  misinterpreted: 

(1)  Guide  and  Guidance.  Do  not  use  the  words 
"guide"  and  "guidance"  as  they  are  subject  to  varied 
interpretations.  Comply  with  the  following: 

(a)  If  drawings,  samples,  or  other  data  are 
to  be  furnished  for  information  and  are  not  mandatory, 
state  that  they  are  furnished  for  "information  only." 

(b)  If  mandatory  that  drawings,  samples,  or 
other  data  be  adhered  to,  state  "the  item  shall  be  in 
accordance  with  the  drawings  (samples  or  other  data)." 


(2)  Shall,  Will,  Should,  and  May.  Use  these 
words  as  follows: 

(a)  The  word  "shall"  is  mandatory  and  not 
subject  to  misinterpretation. 

(b)  The  word  "will"  is  used  to  express  a 
declaration  of  purpose  on  the  part  of  the  government;  for 
example,  the  government  will  furnish  shipping  instructions. 

(c)  The  words  "should"  and  "may"  are  used  to 
indicate  nonmandatory  or  optional  provisions. 

(3)  And/Or.  Use  of  the  phrase  "and/or"  is  ambiguous 
and  should  not  be  used.  It  permits  the  contractor  to  make 
his  own  choice.  For  example,  instead  of  stating  that  the 
surface  shall  be  painted  and/or  coated  (which  has  three 
interpretations),  the  requirement  should  be  stated  as  follows: 

(a)  "The  surface  shall  be  both  painted  and 
coated"  (meaning  both  methods  of  protection  are  required) . 

(b)  "The  surface  shall  be  painted  or  coated, 
or  both  coated  and  painted"  (meaning  the  contractor  is 
given  his  choice  in  the  method  of  protection. 

(4)  Flammable  and  Nonflammable.  The  words  "flam- 
mable" and  "nonflammable"  are  used  in  lieu  of  the  words 
"inflammable"  and  "uninflammable." 

A SUMMARY  OF  THE  GUIDELINES  FOR  SOUND  STATEMENT  OF  WORK 
WRITING 


As  a reminder,  here  is  a checklist  for  the  writing  of 
a more  easily  understandable  statement  of  work: 

a.  Develop  a clear  organizational  pattern  for  the  SOW. 

b.  Use  acceptable  English.  Use  grammar  and  punctation 
functionally.  Avoid  incomplete  sentences.  Place  all  modifiers 
correctly. 

c.  Know  your  readers. 

d.  Use  only  necessary  words -and  conventional  language 
to  the  maximum  extent  practicable.  Make  every  word  count. 

Use  precise  and  graphic  terms. 
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e.  Avoid  jargon,  undefined  acronyms,  and  unfamiliar 
words.  Write  to  express  rather  than  impress.  Prefer  the 
simple  to  the  complex. 

f.  Employ  a consistent  writing  style. 

g.  Write  short,  meaningful  sentences  that  combine 
related  ideas.  Write  paragraphs  that  specifically  inform 
the  contractor  what  is  expected  of  him. 

h.  Put  action  in  your  verbs;  write  in  the  active  voice. 
Avoid  useless  phrases  that  express  a condition  rather  than 
an  action. 

i.  Emphasize  the  main  points. 

The  application  of  this  checklist,  coupled  with  the 
writing  guidelines  contained  in  this  chapter  and  the  R&D 
SOW  General  Principles  of  Chapter  i,  should  materially 
assist  the  project  engineer  in  his  efforts  to  write  a 
clear,  concise,  and  complete  statement  of  work. 
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CHAPTER  5 


FORMAT  CONSIDERATIONS  FOR  STATEMENT  OF 
WORK  PREPARATION 


THE  FORMAT  REQUIREMENT:  BENEFITS  VERSUS  BURDENS 


Project  engineers  occasionally  object  to  the  imposition 
of  a format  requirement  for  the  statement  of  work  on  the 
grounds  that  it  tends  to  inhibit  them  in  the  meaningful  expres- 
sion of  their  ideas.  In  addition,  a specified  format  may 
frequently  require  a project  engineer  to  devote  more  time  to 
SOW  preparation  than  he  judges  is  necessary  for  the  clear 
communication  of  project  requirements.  However,  if  a project 
engineer  has  a thorough  understanding  and  knowledge  of  the 
objective,  purpose,  nature  and  detailed  requirements  for  his 
project  prior  to  attempting  to  comply  with  format  requirements, 
he  should  be  able  to  write  his  statement  of  work  in  accordance 
with  any  format. 

Let's  look  at  the  nature  of  the  format  requirement  as 
specified  in  AFSCP  800-6;  Statement  of  Work  Preparation 
Guidelines . The  pamphlet  specifically  states  that  the formats 
proposed  for  each  type  of  procurement  are  nothing  more  than 
samples  to  guide  AFSC  personnel  in  the  documentation  of  project 
requxrements  and  tasks.  It  additionally  advises  that  each  SOW 
should  be  tail'  red  to  meet  the  needs  of  a specific  program. 
Clearly,  meaningful  and  complete  statement  of  work  content 
is  more  important  than  format  adherence. 

There  are,  however,  distinct  advantages  in  pursuing  some 
degree  of  standardization  at  the  major  paragraph  level  in  R&D 
statements  of  work.  An  organized  SOW  format  allows  all 
readers  to  uniformly  relate  to  the  basic  project  engineer 
thought  pattern  in  the  SOW  content.  They  will  be  able  to 
readily  identify  and  differentiate  between  general  informa- 
tion, project  requirements,  and  deliverable  contract  end 
products/services.  In  addition,  if  all  the  AFSC  laboratories 
utilize  the  same  basic  major  paragraph  level  format,  then 
contractors  accomplishing  or  pursuing  v/ork  with  more  than 
one  laboratory  will  have  a reduced  chance  of  requirement 
misinterpretation  as  a result  of  widely  varying  formats. 

They  will  be  able  to  write  technical  proposals  that  will 
not  require  SOW  clarifications  because  project  requirements 
have  been  masked  by  format  considerations.  Finally,  a 
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format  requirement  helps  a project  engineer  and  his  SOW 
writing  team  avoid  the  possibility  of  omitting  important 
requirements  or  tasks  from  the  body  of  the  document. 

FORMAT  FOR  RESEARCH  AND  DEVELOPMENT  STATEMENTS  OF  WORK 

Statements  of  work  vary  from  complex  R&D  systems  to 
statements  of  performance  requirements  or  objectives  for 
feasibility  studies,  experimental  equipment,  data,  etc. 

The  general  format  and  headings  for  research  and  technology 
statements  of  work  are  as  follows: 


1.0  Introduction  (Objectives). 

2.0  Scope  . 

3.0  General  Background  (information,  constraints, 
and  reference  documents) . 

4.0  Tasks/Technical  Requirements. 

5.0  Reports,  Data,  and  other  Deliverables, 
Attachments,  as  appropriate. 

6.0  Special  considerations. 

EXAMPLE  - RESEARCH  AND  DEVELOPMENT  STATEMENT  OF  WORK 

The  following  example  should  be  used  by  project 
engineers  as  a guide  in  describing  technical  tasks.  For 
ease  of  correlation  to  the  format  just  presented,  the  SOW 
element  descriptions  are  numbered  to  match. 

1.0  INTRODUCTION  (OBJECTIVE).  (The  introduction 
is  intended  to  give  a brief  overview  of  the 
specialty  area  and  describes  why  this  par- 
ticular new  program  is  being  pursued.  The 
overall  requirement  which  needs  fulfillment , 
the  present  difficulties  or  deficiencies 
which  do  not  permit  the  requirement  to  be 
met,  and  the  determinations  which  must  be  made 
to  solve  the  problems,  should  be  outlined 
briefly,  in  fully  understandable  terms.  Quite 
often  an  understanding  of  the  value  of  the 
technical  objective  can  be  reinforced  by 
inclusion  of  an  explanation  of  the  payoff  that 
this  technical  objective  will  have  to  future 
Air  Force  system  capability.  In  framing  the 
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objective,  think  clearly  on  how  the  results 
will  be  used.  The  stated  objective  should 
be  consistent  with  the  funds  planned  and/or 
with  the  minimum  requirements.) 

2.0  SCOPE.  (This  section  provides  an  overall 
picture  of  the  desired  work  in  concise  form. 
The  scope  will  outline  the  various  phases 
of  the  program  and  tie  down  the  overall 
limits  of  the  program  in  terms  of  specific 
technical  objectives,  time  and  any  special 
provisions  or  limitations.  It  must  be  con- 
sistent with  the  detailed  requirements. 

This  section  should  also  describe  in  a 

clean-cut  statement  the  end  result  desired 
or  what  the  "product"  of  the  effort  should 
be.  Don't  overextend  the  magnitude  expected 
or  an  overrun  may  be  the  result.) 

2.1  (Work  outside  the  scope  involves  new 
negotiations  and  may  cause  increased 
costs.  The  manner  in  which  scope  is 
defined  will  govern  the  amount  of 
direction  that  a project  engineer  can 
give  and  that  the  contractor  will 
accept  during  the  contract's  life.) 

3.0  GENERAL  BACKGROUND.  (Include  any  background 
information,  explanations,  or  constraints 
which  are  necessary  in  order  to  understand 
the  requirements.  Discuss  how  the  procure- 
ment arose;  indicate  its  relationship  to 
previous,  concurrent,  and  future  operations t 
including  the  threat  analysis,  and  relate 
details  which  reveal  its  purpose  and  signi- 
ficance. Statements  on  the  importance  of 

the  new  work  may  also  be  included.  Techniques 
which  have  previously  been  tried  and  found 
ineffective  should  be  included.  Frequently 
it  is  best  to  leave  the  writing  of  the  back- 
ground to  the  last.  The  listing  of  applicable 
technical  reports  resulting  from  the  DDC 
bibliography  search  should  be  entered  here. 

Any  such  listing  in  this  paragraph  is  for 
information  only  and  not  contractually 
obligatory . ) 
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3.1  APPLICABLE  DOCUMENT  LIST.  (All  contractu- 
ally applicable  documents  must  be  cited 
either  in  the  text  of  the  appropriate  task 
or  in  a separate  paragraph  entitled  "Appli- 
cable Documents  List."  If  there  were  no 
applicable  reports,  a comment  to  this  effect 
should  be  made  on  the  supplemental  sheet  to 
the  puxwhase  request  but  not  included  in  the 
SON.) 

4.0  TECHNICAL  REQUIREMENTS/TASKS.  (This  paragraph 
should  define  the  work  to  be  accomplished  and 
indicate  the  main  steps  and  actions  which  are 
required  of  the  contractor  to  properly  conduct 
the  program.  These  main  steps  constitute  the 
work  phases  (recommended  approach) . The  tech- 
nical leadership  provided  by  the  Government  in 
planning  and  establishing  the  contractual 
program  appears  here.  It  should  not  reflect 
an  attitude  that  this  is  the  only  approach  to 
the  problem.  It  should  state  that  this  is  a 
suggested  method  but  new  or  unique  ideas 
supported  by  available  data  are  acceptable  and 
encouraged.  This  paragraph  also  gives  known 
specific  phenomena,  methods  which  could  contri- 
bute to  a solution,  possible  correlation  with 
existing  knowledge,  operational  and  installation 
environments  anticipated  for  the  ultimate  opera- 
tional equipment,  and  such  other  factors,  including 
all  available  foreign  technology  information,  as 
would  tend  to  assure  that  the  contractor  would 
conduct  a fully  effective  program.) 

4.x  (The  statement  of  work  should  express  the 
minimum  performance  which  will  satisfy 
operational  requirements.  Minimum  accept- 
able requirements  are  the  least  possible 
requirements  necessary  to  assure  the  item(s) 
specified  will  do  exactly  that  which  is 
intended.  Requirements  must  be  definite, 
realistic,  and  clearly  stated  so  they  can 
be  met  at  a practical  cost  in  money,  labor, 
and  raw  material.  The  art  of  converting 
requirements  to  descriptive  text,  written 
technical  matter,  requires  a certain  degree 
of  skill  in  the  choice  of  words  and 
utilization  of  certain  terms.  Often  the 
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inadvertent  misuse  of  words  such  as 
and/or,  but,  shall,  will,  may,  and 
other  will  alter  the  legal  meaning  of 
the  document  to  such  an  extent  that  the 
Government  may  not  receive  the  required 
end  product/service.) 

4.1.1  (Describe  the  requirement  in 
complete  detail  not  only  for  legal 
reasons  but  also  for  practical 
application.  It  is  easy  to  over- 
look many  details;  it  is  equally 
easy  to  be  repetitious.  Beware  of 
both!  For  every  piece  of  deliver- 
able hardware,  for  every  report, 
for  every  important  action,  there 
is  not  only  the  what  but  also  the 
when  and  the  where.  If  it  is 
necessary  to  omit  a quantity  or 
time  and  to  specify  that  something 
shall  be  done  as  necessary  specify 
whether  the  judgement  is  to  be  made 
by  the  contractor  or  the  Government. 
Remember  that  these  types  of  con- 
tingent actions  have  impact  on  the 
price.  Where  expensive  services 
such  as  technical  liaison  are  to  be 
furnished,  do  not  just  say  as  required. 
Provide  a ceiling  on  the  amount  or 
work  out  a procedure  that  will  ensure 
reasonableness  and  Government  control. 
The  number  and  type  of  proposals 
received  and  adequacy  of  procing  will 
be  greatly  dependent  upon  the  content 
and  phraseology  used  in  the  technical 
SOW. ) 

4.1.2  (The  statement  of  work  should  be 
specific  as  to  the  end  result  desired 
or  expected;  the  conduct  of  research 
and  development  is  not  the  objective 
in  itself.  Relevance  to  military 
application  should  be  indicated.) 
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4,1..,.'*  (Work  statements  will  be 
structured  and  numbered 
icording  to  the  multi - 
numeric  decimal  system 
i.f  Lustra  ted  in  this  example . ) 

4. 1.2. 2 (The  technical  requirements 
and/or  work  requirements 
should  be  arranged  in  logical 
order.  Care  should  be 
exercised  to  exclude  any 
phraseology  that  is  subject 
to  misinterpretation.) 

4. 1.2. 3 (Work  statements  should  be 
as  definitive  as  possible 
such  that  they  may  be  included 
in  any  resultant  contract..) 


4.2  (If  the  work  encompasses  several  areas  or 
lends  itself  to  division  into  tasks,  this 
should  be  indicated.  The  essential  pro- 
cedures (that  is,  theoretical  analyses, 
design,  fabrication,  checkout,  tests, 
verification,  formulation  of  final  recom- 
mendations, etc.),  with  limits  on  each, 
constitute  the  bulk  of  this  paragraph. 

In  some  cases,  the  engineer  may  wish  to 
indicate  the  percent  of  the  total  effort 
each  phase  is  to  receive.  If  there  are 
existing  specifications  with  paragraphs 
that  define  what  you  want  to  have  the 
contractor  do  in  terms  of  tests,  etc., 
use  them  (incorporate  by  reference,  as 
appropriate)  rather  than  compose  original 
paragraphs.  Specify  those  considerations 
which  may  guide  the  contractor  in  his 
analysis,  design,  or  experimentation  on 
the  designated  problem.  These  should  include 
operational  characteristics  (if  any)  or 
other  factors  the  contractor  is  expected 
to  consider  in  performing  under  the  contract.) 


4.2.1  (Each  task  and  deliverable  end  item 
should  be  identified  to  a specific 
period  of  performance  or  delivery 
date.  It  is  the  responsibility  of 
the  writer  to  establish  this 
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requirement  as  a part  of  the  program 
management  task  of  the  SOW.  While 
the  period  of  performance  or  delivery 
schedule  may  be  integrated  into  each 
task  description  in  the  SOW/  a schedule 
summary  is  sometimes  provided  as  a 
separate  document  so  that  it  can  be 
used  as  an  exhibit  to  the  request  for 
proposal  (RFP)  and  subsequently  incor- 
porated in  the  body  of  the  contract. 
Delivery  schedule  may  be  stated  in 
terms  of  calendar  days  elapse  time 
(that  is,  223  calendar  days  after 
contract  award)  or  by  a specific 
calendar  date,  that  is,  1 May  1973.) 

2.2  (In  statements  of  work  requiring  the 
contractor  to  perform  testing,  the 
test  requirements  will  be  clearly 
and  adequately  stated  and  must  cor- 
relate with  the  design  requirements 
so  that  contractor  testing 
responsibilities  are  defined.) 

4. 2. 2.1  (Where  properties  of  materials 
are  desired,  each  individual 
property  and/or  test  should 

be  specified.) 

4. 2. 2. 2 (If  it  is  desired  to  have  the 
contractor  choose  materials  to 
be  evaluated,  so  state  (with 
limits  - so  the  contract  may 
be  priced  accordingly)  or  to 
make  "subject  to  approval  of 
the  Contracting  Officer.") 

2.3  (Consider  the  necessity  of  including 
guidance  relative  to  special  technical 
factors  or  requirements.) 

4. 2. 3.1  (Qualitative  reliability  and 
maintainability  requirements 
may  be  expressed.) 

4. 2. 3. 2 (System  safety  requirements 
may  be  expressed.) 


4.2.4  DEFINITIONS.  (In  many  instances , 
the  inclusion  of  a definition  can 
be  avoided  if  requirements  are 
properly  stated.  When  the  meaning 
of  one  or  more  terms  must  be  estab- 
lished, definition  should  be  placed 
in  the  SOW.  A single  definition 
may  appear  immediately  following 
the  term  where  used.  However,  it  is 
often  clearer  to  list  one  or  more 
definitions  in  a separate  section 
when  the  terms  are  used  in  many 
places  throughout  the  document.) 

4.3  (Be  sure  that  limits  of  environment,  test 
durations,  combustion  pressures,  data 
recording,  expansion  ratio,  mixture  ratio, 
range  of  particle  size,  etc.,  are  specified. 
Criteria  governing  the  number  of  designs, 
types  of  propellants,  performance,  hard- 
ware size,  number  of  tests,  etc.,  and 
constraints  such  as  budget,  environmental 
producibility  and  risk  levels  should  be 
included  in  the  definition  of  the  work  to 
be  done  by  the  contractor . ) 

4.4  COMMIT  YOURSELF.  (When  the  burden  of 
definition  must  be  placed  on  the  offeror, 
clearly  impose  the  requirement  in  a manner 
so  he  understands  that  he  must  provide  this 
definition  in  the  proposal  (if  this  is  what 
is  wanted)  or  later  on  in  the  contractual 
program  (if  this  is  the  intent) . Any 
specific  limitation  such  as  "not  desired" 
or  "previously  tried"  techniques  should  be 
stated.  If  there  is  a primary  area  with 

a secondary  contributing  or  limiting  area, 
they  both  should  be  defined.  Experimental 
or  installation  environments  (known  or 
anticipated) , scientific  or  technical  per- 
sonnel, other  resources  should  be  indicated. 
When  the  offeror  provides  definition  or  plans, 
it  should  be  stipulated  that  these  are  subject 
to  Air  Force  approval . ) 


4.5  (A  description  should  be  given  of  any  end 
item  that  is  the  subject  of  development. 

It  will  firmly  and  clearly  define  the 
required  work  for  such  tasks  as  those  listed 
below. 

- Review  of  current  literature  to 
establish  a basis  for  further 
research,  analysis,  investigation, 
or  experimentation. 

- Search  for  new  ideas  through 
investigation  of  various  phenomena. 

- Paper  or  theoretical  analysis  of 
ideas  in  relation  to  requirements, 
ultimate  use,  and  trade-off  capabilities. 

- Computational  analysis  and  formulation 
of  mathematical  model. 

- Experimentation  to  evolve  methods  of 
instrumentation . 

- Derivation  of  a basic  equipment  design 
or  experimental  assemblies. 

- Test  and  evaluation . ) 

4.5.1  (Trade  names,  copyrighted  names , or 
other  proprietary  names  applying 
exclusively  to  the  product  of  one 
company  shall  not  be  used  unless  the 
item(s)  cannot  be  adequately  described 
otherwise  because  of  being  peculiar 
to  one  (or  a few)  companies.  In  such 
instances,  one  and,  if  possible,  several 
commercial  products  may  be  included, 
followed  by  the  words  "or  equal"  to 
assure  wider  competition  and  that 
bidding  will  not  be  limited  to  a 
particular  make  specified.  The  same 
applies  to  manufacturer’s  part  num- 
bers or  drawing  numbers  for  minor  parts 
when  it  is  impractical  to  specify  the 
exact  requirements  in  the  SOW  or  exhibit. 
Insofar  as  practical,  the  particular 


characteristics  required  shall  be 
included  to  define  "or  equal." 

Before  making  a reference  to  any 
commercial  designation,  check 
carefully  to  be  sure  there  is  no 
military  specification  or  standard 
covering  the  item.  If  necessary  to 
use  "or  equal,"  limit  it  to  minor 
items . ) 

4.6  (Do  not  repeat  detailed  requirements  of 
applicable  documents  specifications,  etc. 
However,  if  amplification,  modification, 
or  exceptions  are  required,  make  specific 
references  to  the  applicable  portion  of 
the  documents  involved  and  state  the 
requirement . ) 

4.7  (If  the  state-of-the-art  is  such  that  one 
or  more  specific  methods  of  approach  to 
the  solution  are  to  be  followed,  this 
section  should  indicate  the  desired  approach. 

If  no  specific  approach  is  primarily  war- 
ranted and  one  will  be  determined  on  the 
basis  of  the  selected  contractor's  technical 
proposal,  this  section  should  include  a 
statement  of  criteria  on  which  contractor 
proposal  of  alternative  approaches  will  be 
based. ) 

4.8  SCIENTIFIC  AND  TECHNICAL  INFORMATION  (STINFO) . 

(Insert  the  following,  if  applicable:  "The 

contractor  shall  search  the  existing  sources 
of  STINFO  to  determine  the  current  state-of- 
the-art  to  avoid  duplication  of  effort  and 
conserve  scientific  and  technical  resources." 
Ensure  that  all  generated  STINFO  that  has  a 
significant  value  to  the  pertinent  scientific 
and  technical  communities  is  furnished  to  DDC.) 

5.0  REPORTS,  DATA,  AND  OTHER  DELIVERABLES.  (Contract 
data  or  reporting  requirements  should  not  be 
duplicated  in  the  SOW.  DD  Form  1423  is  the  medium 
for  establishing  data  requirements.  The  SOW  may 
refer  tc  the  DD  Form  1423  incorporated  in  the 
contract  by  reference  or  even  to  any  particular 
data  item  for  clarifying  a requirement.  If  deliv- 
erable hardware  is  required,  it  should  also  be 
listed  in  this  section  as  a separate  paragraph. ) 
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5.1  (APSC  Regulation  310-1  provides  policies 
and  procedures  for: 

5.1.1  Preparing  DD  Form  1423,  Contract 
Data  Requirements  List,  which 
becomes  a contract  exhibit. 

5.1.2  Using  DOD  Standard  DD  Forms  1664, 

Data  Item  Description,  which  are 
contractually  incorporated  by 
reference  on  DD  Form  1423  and 
govern  the  delivery  of  all  data, 
other  than  ASPR  requirements  in 
the  general  or  special  contract 
provisions. 

5.1.3  Developing,  approving,  and  using 
program  peculiar,  or  unique,  data 
requirements  as  well  as  modifica- 
tions to  capitalize  upon  contractor 
internal  data  in  relaxed  format. 

With  few  exceptions,  all  deliverable 
data  is  directly  related  to  work 
statement  tasks  that  generate  the 
data;  however,  nothing  in  the  SOW 
can  call  for  the  delivery  of  data. 
Unless  specific  data  requirements 
are  a by-product  of  the  SOW,  they 
will  be  subject  to  question  and 
challenge . ) 

5.2  (If  the  contractor  is  to  furnish  samples, 
the  number  and  size  must  be  stated.  All 
samples  specified  must  be  clearly  described 
as  "research  samples"  when  RDT&E  funds  are 
used . ) 

6.0  SPECIAL  CONSIDERATIONS.  (A  paragraph  outlining 
any  special  interrelationships  between  the  con- 
tractor and  other  agencies  or  other  contractors 
for  use  of  Government-furnished  or  loaned  property 
may  be  devised  and  added  to  the  SOW  as  paragraph 
6.0.  Any  other  specific  directions  relative  to 
technical  work  (not  administrative  matters)  for 
the  contractor  to  follov;  should  be  included  here. 
If  a flight  test  program  with  USAF  aircraft  is 
involved,  the  contractor's  maintenance  and 
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safety-of-flight  responsibilities  will  be  out- 
lined; however/  be  careful  not  to  duplicate 
any  of  the  special  provisions  or  general  pro- 
visions of  the  contract.  This  paragraph  might 
also  provide  instructions  to  the  contractor 
relative  to  the  possible  use  of  Government 
expertise;  for  example,  the  availability  of 
AFML  assistance  in  determining  the  state-of- 
the- production- art  and  the  practical  availability 
of  new  technology.) 

6.1  (Spell  out  carefully  all  obligations  of  the 
Government.  If  Government-furnished  equip- 
ment (GPE)  is  to  be  provided,  state  the 
nature,  condition,  and  time  availability 

of  the  equipment;  also,  how  it  is  to  be 
refurbished  and  restored.  If  approval 
actions  are  to  be  made  by  the  Government, 
provide  for  a time  limit.  Remember  that 
any  provision  which  takes  control  of  the 
work  away  from  the  contractor,  even  tem- 
porarily, will  invite  a contingency  reserve. 

Do  not  build  in  the  need  for  contingencies . ) 

6.2  SECURITY.  (A  DD  Form  254,  Contract  Security 
Classification  Specification,  may  be  developed 
for  procurement  actions,  based  on  the  specific 
content  of  the  SOW  measured  against  the  master 
security  classification  guide  for  the  indi-3- 
vidual  program.  The  SOW  writer  should  include 
any  security  constraints  or  international 
aspects  that  will  have  a significant  effect 

on  performance  of  the  work  to  be  accomplished.) 

AMENDMENTS  AND  REVISIONS  TO  THE  STATEMENT  OF  WORK 


It  is  not  uncommon  for  statements  of  work  to  need  modifi- 
cation as  a result  of  content  problems  identified  in  the  SOW 
either  prior  or  subsequent  to  contract  award.  The  modifications 
fall  into  two  distinct  categories:  amendments  or  revisions. 

An  amendment  to  a statement  of  work  is  normally  used  for 
correction  of  typographical  errors  and  mistakes  in  grammar  and 
punctuation.  It  is  also  used  to  make  additions  or  deletions 
of  information  to  improve  clarity  and  minor  requirement  changes. 
An  amendment  does  not  cause  a change  in  the  numerical  identifier 
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of  the  SOW.  It  is  accomplished  on  a separate  document 
and  requires  no  change  in  the  form  of  the  basic  SOW.  As 
a general  rule  of  thumb,  an  amendment  should  be  written 
when  the  amount  of  change  to  information  contained  in  the 
basic  SOW  does  not  exceed  25  percent. 

Amendments  are  identified  in  numerical  sequence.  Each 
successive  amendment  to  the  basic  SOW,  written  prior  to 
contract  award  should  incorporate  all  changes  to  require- 
ments established  in  the  SOW  from  the  previous  amendment. 

It  should  also  include  all  unchanged  requirements  or  changes 
from  the  previous  amendment.  When  completed,  it  will 
supersede  any  previous  amendment  in  its  entirety.  The  format 
to  be  used  for  amendments  is  the  same  as  the  basic  SOW. 

If  the  amendment  is  required  after  the  contract  award, 
coordination  must  be  accomplished  with  the  contracting  officer 
prior  to  the  preparation  of  the  amendment.  This  action  is 
necessary  to  permit  the  contracting  officer  to  decide  upon 
the  best  method  of  preparing  and  including  the  required 
changes  in  the  contract.  The  contracting  officer  may  determine 
it  to  be  more  feasible  to  prepare  the  next  successive  amendment 
to  cover  changes  that  have  transpired  since  contract  award. 

He  may  not  supersede  the  previous  amendment (s)  which  are  now 
covered  in  the  contract.  In  this  case,  a supersession  note 
at  the  top  of  the  amendment  may  not  be  included.  The  state- 
ment that  will  be  attached  to  this  amendment  will  read  similar 
to  the  following:  "This  amendment  forms  a part  of  statement 

of  work  AFHRL-C-2 468,  1 September  19XX,  and  amendment  3, 
dated  20  December  19XX. " 

Each  individual  correction  contained  in  the  amendment 
is  presented  separately  and  the  particular  page,  paragraph, 
table,  or  figure  to  which  the  change  applies  is  identified. 

The  imperative  form  of  the  verb  is  used  in  the  amendment  to 
indicate  the  changes  to  be  made.  When  paragraphs  are  deleted 
from  the  basic  SOW,  the  remaining  paragraphs  in  the  section 
should  not  be  renumbered.  When  new  requirements  are  added 
to  the  basic  SOW  by  the  amendment,  they  are  added  in  such  a 
way  that  paragraph  renumbering  is  unnecessary. 

Revisions  are  made  to  the  basic  statement  of  work  when 
the  changes  involved  are  of  considerable  length  in  relation 
to  the  size  of  the  basic  SOW  or  for  major  format  changes.  A 
revision  should  be  made  when  any  combination  of  major  or 
minor  changes  total  more  than  25  percent  of  the  basic  SOW. 
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The  25  percent  rule  of  thumb  for  revisions  also  applies 
when  the  total  amendments  made  to  a particular  SOW  amount 
to  a 25  percent  change.  When  revisions  are  made,  all 
requirements  should  be  analyzed  and  brought  up-to-date  as 
far  as  practicable. 

Revisions  to  an  SOW  are  indicated  by  the  additions  of 
a capital  letter  following  the  basic  contract  numerical 
identifier,  such  as,  AFHRL-C-2468A.  Succeeding  revisions 
should  be  indicated  by  the  remaining  letters  of  the 
alphabet  in  alphabetical  sequence.  A revision  is  an  issue 
superseding  the  previous  document  in  entirety  with  all 
pages  being  identified  by  the  same  applicable  revision 
letter . 

CONCLUSION 

The  reader  may  have  noticed  that  the  major  paragraph 
level  format  recommended  in  this  chapter  aligns  itself 
rather  closely  with  the  guidelines  recommended  for  planning, 
organizing,  and  writing  a SOW.  If  a project  engineer  can 
maintain  this  close  relationship  between  the  planning, 
organizing,  writing,  and  format  considerations  for  his  SOW, 
he  may  find  that  the  final  writing  of  his  statement  of  work 
will  be  a much  easier  task. 


CHAPTER  6 


REVIEWING  THE  STATEMENT  OF  WORK 


INTRODUCTION 


If  a project  engineer  has  been  successful  in  writing 
a quality  statement  of  work/  then  he  and  his  Procurement 
Contracting  Officer  (PCO)  can  substantially  enhance  their 
chances  of  satisfying  the  R&D  project's  requirements  with 
a better  contract  requiring  less  financial  resources  and 
technical  effort.  In  our  present  inflationary  era  where 
the  value  and  amount  of  R&D  funds  are  decreasing  in  real 
terms,  project  engineers  cannot  afford  to  become  compla- 
cent or  indifferent  with  regard  to  SOW  preparation.  The 
very  existence  of  their  projects  has  become  dependent 
upon  their  project  preparation  and  management  abilities. 

Vague  and  ambiguous  SOWs  can  quite  differently  cause 
poor  contract  performance  and  a virtually  endless  continuum 
of  contract  management  problems.  Project  goals  may  never 
be  achieved  or  successfully  pursued  regardless  of  the 
nature  of  the  technical  risk  in  the  project.  In  those  cases 
where  the  contract  can  be  carried  out  to  successful  comple- 
tion, the  amount  of  supplementary  funds  and  schedule 
slippages  required  to  correct  SOW  deficiencies  may  be  very 
significant.  In  order  to  preclude  this  type  of  SOW  from 
being  written  and  used  in  a contract,  it  is  strongly  recom- 
mended that  the  project  engineer  institute  a SOW  review 
procedure  that  will  extend  from  the  day  he  starts  to  prepare 
his  SOW  to  the  day  when  the  resultant  contractual  effort  has 
been  completed. 

When  prospective  contractors  are  writing  their  technical 
proposals,  they  frequently  subject  them  to  a rigorous  internal 
review.  The  proposals  are  given  to  company  employees  only 
slightly  familiar  with  the  proposed  project.  The  employees 
are  asked  if  they  understand  the  message  being  communicated 
in  the  proposal.  They  are  also  asked  to  review  the  SOW  and 
determine  whether  the  proposal  responds  to  or  deviates  from 
the  requirements  of  the  SOW.  When  gaps  are  found  between 
the  SOW  and  the  company  proposal,  efforts  are  initiated  to 
refine  the  proposal  content  or  add  supplementary  data  to 
strengthen  the  proposal.  The  project  engineer  is  well  advised 
to  use  the  same  strategy  within  his  laboratory  and  procurement 
organization  in  order  to  assure  the  teamwork  approach  for  both 
SOW  preparation  and  review. 


REVIEW  THE  STATEMENT  OF  WORK  WHILE  IT  IS  BEING  WRITTEN 
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It  is  helpful  for  the  project  engineer,  who  has  primary 
responsibility  for  formulating  the  SOW,  to  routinely  evaluate 
the  quality  of  the  work  statement  as  preparation  progresses. 

In  any  case,  he  keeps  in  mind  the  main  criteria  needed  to 
judge  whether  the  material  in  the  SOW  is  correctly  included. 

The  following  tests  of  SOW  material  applicability  have  been 
mentioned  in  numerous  places  in  the  pamphlet.  They  are  repeated 
here  for  ease  of  location  and  mainly  for  emphasis.  They  are: 

a.  Does  this  information  tell  the  contractor  what  he 
is  required  to  do? 

b.  Is  this  information  necessary  to  assist  the  contractor 
in  understanding  what  is  required  of  him? 

c.  Will  the  contractor  and  the  Air  Force  be  able  to 
negotiate  reasonable  pricing  parameters  for  these  items  (tasks) , 
services , etc . ? 

d.  Will  the  tasks,  when  accomplished,  produce  results 
consistent  with  project  objectives? 

CHECKLIST  FOR  STATEMENT  OF  WORK  REVIEW 

A practical  means  of  reviewing  the  SOW  is  to  ask  knowl- 
edgeable and  experienced  associates  to  read  and  critique  the 
SOW  prior  to  submission  for  approval.  When  fe21ow  project 
engineers,  functional  experts,  and  other  procurement  representa- 
tives are  requested  to  provide  their  comments,  it  is  often 
possible  to  discover  ambiguities,  inconsistencies,  and  other 
deficiencies  before  seeking  approval  in  the  RFP  process  and, 
more  importantly,  before  transmittal  tc  prospective  sources. 

The  main  test  is  always  "Is  it  clear?,"  and  cold  readings  by 
others  in  the  review  process  point  up  those  aspects  not 
immediately  discernible  to  authors. 

The  following  checklist  is  recommended  for  use  by  all 
personnel  reviewing  a SOW.  It  is  an  extensive  list  but  it 
is,  by  r.o  means,  complete.  It  should  be  tailored  or  expanded 
to  meet  the  needs  of  the  specific  SOW  undergoing  the  review 
process.  The  checklist  may  enable  all  SOW  reviewers  to  keep 
foremost  in  their  minds  the  salient  feature  of  the  review 
process  objectives  while  the  SOW  is  being  prepared  or  prior 
to  its  inclusion  into  the  RFP. 
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a.  Have  the  required  project  objectives  and  desired 
results  been  clearly  and  specifically  described? 

b.  Has  adequate  background  information  been  provided 
that  would  be  helpful  to  a clear  understanding  of  the 
requirements  and  how  they  evolved? 

c.  Have  technical  considerations  such  as  any  known 
specific  phenomena  or  techniques  been  clearly  presented? 

d.  Does  the  SOW  include  a detailed  description  of  the 
technical  requirements  and  subordinate  tasks? 

e.  Is  the  required  technical  effort  feasible  for 
contractor  performance  by  reason  of  the  SOW  language? 

f.  Does  the  state-of-the-art  support  the  prescribed 
goals  as  being  realistic? 

g.  Has  the  risk  of  performance  been  minimized  to  the 
maximum  practical  extent  by  the  elimination,  whenever  possible, 
of  items  or  considerations  not  absolutely  needed  for  the 
successful  accomplishment  of  the  project?  Have  "nice  to  have" 
or  redundant  requirements  been  eliminated  from  the  "essential" 
items? 

h.  Is  the  SOW  sufficiently  specific  to  permit  both  the 
project  engineer  and  any  prospective  contractor  to  make  a 

list  of  the  manpower,  special  facilities,  equipment,  subcontract 
or  consultant  resources  (whichever  are  applicable)  needed  to 
accomplish  the  project? 

i.  Does  the  SOW  content  permit  prospective  contractors 
to  prepare,  as  required,  estimated  costs  for  each  task  or 
performance  area? 

j . Is  general  information  separated  from  technical 
requirements/ tasks  so  that  background  information,  suggested  ’ 
procedures,  and  the  like  are  clearly  distinguishable  from 
contractor  responsibilities? 

k.  Are  the  specific  duties  of  the  contractor  stated  in 
such  a way  that  he  knows  what  is  required  and  the  government 
agent  who  signs  the  acceptance  report  can  tell  whether  the 
contractor  complied? 


l.  Are  contractor  requirements  clearly  and  appropriately 
stated  including  standards  which  make  it  possible  for  both 
government  and  contractor  personnel  to  measure  performance? 

m.  Have  the  appropriate  milestones  been  introduced  into 
the  SOW  for  aJl  tasks  that  require  a government  review  and 
approval  or  acceptance/rejection  decision  before  the  contractor 
proceeds  to  accorplish  additional  effort? 

n.  Are  the  proper  reference  documents  shown?  Are  they 
pertinent  to  the  task?  Fully  or  partially?  Are  they  properly 
cited  in  the  SOW? 

o.  Are  any  military  specifications  or  standards  applicable? 

In  whole  or  in  part?  If  so,  are  they  properly  cited?  Has  the 
latest  available  revision  or  issue  of  each  appropriate  document 
been  quoted? 

p.  Have  reporting  requirements  and  any  other  deliverables 
(data,  test  support,  experimental  hardv/are,  prototypes,  etc.) 
been  included  in  the  SOW? 

q.  Is  there  a date  for  each  contractor  delivery  require- 
ment? If  "elapse  time"  is  used,  does  it  specify  calendar  days 
or  workdays?  Are  the  proper  delivery  requirements  shown? 

r.  Have  the  type  and  quantity  of  reports  (technical, 
financial,  progress,  etc.)  required  for  delivery  been  specifically 
described  and  specified? 

s.  Have  all  data  requirements  been  reviewed  to  ensure 
compatibility  with  the  data  requirements  specified  on  the  DD 
Form  1423?  Have  all  extraneous  data  requirements  been 
eliminated? 

t.  Have  the  Armed  Services  Procurement  Regulations  (ASPR) 
requirements  relative  to  the  contract  line-subline  identification 
been  followed? 

u.  Has  the  SOW  been  written  as  specifically  as  practicable 
while  providing  the  contractor  the  necessary  flexibility  consistent 
with  project  needs? 

v.  Has  the  role  and  responsibility  of  the  project  engineer 
been  clearly  identified?  Have  special  considerations  been 
properly  documented? 
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REVIEWING  THE  STATEMENTS  OF  WORK  IN  ACTIVE  CONTRACTS 


The  project  engineer's  responsibility  to  review  a SOW 
for  clarity/  coherency,  and  completeness  does  not  stop  at 
the  time  of  contract  award.  A statement  of  work  is  not  a 
static  document  which  is  tailored  to  fit  the  needs  of  a 
specific  R&D  project  prior  to  the  award  of  contract  into  a 
fully  executed  contract.  The  need  to  monitor  the  relevancy 
of  SOW  content  to  project  objectives  continues  throughout 
the  life  of  a contract.  The  technical  requirements,  tasks 
and  contract  deliverables  may  change  as  a result  of  con- 
tractual progress  or  lack  thereof.  Requirements  may  become 
antiquated  and  need  a timely  updating.  They  may  possibly 
become  unattainable  and  require  modification  to  allow  the 
pursuit  of  alternate  technical  requirements  that  can  possibly 
be  achieved  without  jeopardizing  the  project's  objectives. 

The  technological  threat  to  which  the  project  is  responding 
may  be  altered  and  necessitate  a significant  realignment  of 
the  entire  SOW.  Weaknesses  in  content,  undetected  prior  to 
contract  award,  can  materialize  as  the  contractual  effort  is 
being  pursued  and  result  in  contract  management  problems  which 
call  for  immediate  attention. 

The  list  of  things  that  can  go  wrong  with  a SOW  in  an 
R&D  contract  is  virtually  boundless.  As  mentioned  in  Chapter 
1,  research  and  development  is  intrinsically  uncertain  and 
highly  susceptible  to  change.  Consequently,  the  SOWs  written 
for  such  projects  should  be  closely  scrutinized  to  assure  a 
continually  relevant  content  in  an  ever-changing  environment. 

The  project  engineer  always  needs  to  be  current  in  contract 
status.  Amendments  or  revisions,  as  appropriate,  may  have 
to  be  prepared  to  correct  existing  SOW  deficiencies. 

Additional  funds  may  be  required  before  a contractor 
will  accept  and  pursue  SOW  changes.  As  a result,  the  project 
engineer  must  work  in  close  coordination  with  his  Procurement 
Contracting  Officer  in  order  to  assure  that  all  SOW  changes 
are  accomplished  in  an  integrated  orderly  manner.  The  alter- 
native approach,  unilateral  SOW  changes  in  technical  or  delivery 
requirements,  can  precipitate  a range  of  problems  from  cost 
overruns  to  legal  litigations.  For  these  reasons,  procurement 
regulations  specifically  require  that  all  changes  be  initiated 
by  the  project  engineer  through  his  PCO  to  the  contractor 
concerned.  The  PCO  is  the  only  government  official  possessing 
the  authority  to  make  such  changes. 
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REVIEWING  DATA  REQUIREMENTS  AND  TECHNICAL  REPORTS 


The  contract  data  requirements  included  in  R&D  SOWs 
have  historically  not  received  sufficient  project  engineer 
attention  during  the  formulation  process  and  the  negotia- 
tion of  the  resulting  contract.  They  might  not  generate 
any  concern  until  the  contractor  satisfies  the  requirement 
by  delivery.  Unfortunately,,  if  the  required  data  have  not 
been  prepared  and  submitted  in  an  acceptable  manner,  contract 
resources  may  have  been  wasted.  Attempts  to  correct  any 
deficiencies  may  cause  schedule  slippages,  contractor  protests, 
or  possibly  increased  contract  costs. 

Frequently,  project  engineers  and  personnel  supporting 
the  effort  just  identify  their  information  requirements.  They 
may  be  relying  too  heavily  on  the  laboratory  data  specialist 
to  select  the  appropriate  Data  Item  Descriptions  (DD  Form  1664) 
and  consolidate  them  on  the  consolidated  Data  Requirements  List 
(DD  Form  1423) . The  questions  concerning  what  data  is  actually 
needed,  why  it  is  needed,  what  constitutes  acceptable  contractor 
submitted  data,  and  what  is  the  data  cost  impact  on  the  technical 
portion  of  his  project,  really  do  not  receive  proper  project 
engineer  emphasis  prior  to  contract  award.  The  overall  contract 
management  responsibility  lies  with  the  project  engineer. 

However,  when  it  comes  to  data  management,  he  may  have  inad- 
vertently avoided  the  issue.  The  data  manager  or  the  PCO  is 
left  with  the  task  of  resolving  the  data  problem  on  active 
contracts.  This  delegation,  however,  does  not  relieve  the 
project  engineer  of  his  data  management  responsibility. 

There  are  very  high  costs  associated  with  the  generation 
and  preparation  of  contractor  submitted  data.  Consequently, 
it  is  in  the  best  interests  of  the  project  engineer  to  develop 
and  implement  a procedure  which  will  objectively  challenge 
all  data  requirements  required  in  his  SOW.  He  can  then  be 
assured  that  the  contractor  will  provide  only  essential  data 
in  support  of  his  project. 

Checklist  for  Challenging  Data  Requirements. 

The  following  checklist  has  been  prepared  in  order  to 
help  the  project  engineer  determine  that  only  essential  data 
requirements  are  introduced  and  satisfied  in  his  contract. 

The  assistance  of  laboratory  data  management  personnel  should 
be  solicited  in  order  to  ascertain  the  procedures  for  imple- 
menting the  checklist.  It  will  be  noticed  that  the  checklist 
is  divided  into  three  phases  that  extend  across  the  entire 
life  of  the  project. 
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a.  Precontract  Phase  (from  the  start  of  the  SOW 
formulation  process  to  the  submission  of  the  completed 
Purchase  Request  Package  to  Procurement) . A comprehensive 
challenge  of  data  requirements  during  this  phase  provides 
the  project  engineer  with  the  maximum  opportunity  for  data 
cost  avoidance.  The  first  ten  questions  that  will  now  be 
presented  should  be  answered  by  all  personnel  identifying 
data  requirements.  Questions  11  through  13  should  be 
discussed  with  the  data  management  and  procurement  personnel. 

(1)  What  specific  data  is  needed? 

(2)  why  is  it  needed? 

(3)  What  will  actually  be  received  when  a data 
item  is  delivered  by  the  contractor? 

(4)  How  will  the  data  be  used? 

(5)  What  is  the  estimated  value/worth  of  the  data 
with  respect  to  project  accomplishment? 

(6)  How  much  does  the  data  cost? 

(7)  Are  there  alternate  ways  of  obtaining  the  same 
information?  Have  they  been  evaluated?  (The  information 
may  already  be  available  within  the  Government.) 

(8)  Are  potential  contractors  being  encouraged  to 
propose  using  their  internal  formats  for  presenting  data 
when  their  formats  adequately  display  the  information 
required  on  equivalent  government  formats?  The  cost  savings 
can  be  substantial. 

(9)  What  would  be  the  impact  if  the  data  requirements 
were  deleted? 

(10)  Is  the  need  for  the  data  such  that  it  justifies 
the  price  to  be  paid  therefor? 

(11)  Are  deferred  ordering  techniques  being  utilized 
for  data  item  descriptions  satisfying  actual  requirements 

that  cannot  be  economically  determined  prior  to  contract  award? 

(12)  is  deferred  delivery  being  prescribed  in  contracts 
where  data  is  to  be  delivered  but  no  delivery  schedule  has  beer, 
formulated? 
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(13)  Is  deferred  requisitioning  being  employed  in 
contracts  which  can  specify  the  format,  range,  and  kinds 
of  data  to  be  delivered,  via  requisition,  to  the  Government 
along  with  the  ordering  conditions  and  pricing  terms? 

b.  Technical  Proposal  Evaluation  - Negotiation  of 
Contract  Phase.  This  phase  of  the  procurement  process  is 
the  last  opportunity  a project  engineer  has  to  effectively 
avoid  the  cost  of  excessive  data  requirements.  It  will 
require  a c.'ose  working  relationship  between  the  project 
engineer  and  project  supporting  personnel  (technical,  data 
management  and  procurement) . The  objective  is  to  assure 
contractor's  data  proposal  reflects  a compliance  with  the 
DD  Form  1423  data  requirements  and  exhibits  an  acceptable 
data  quantity,  quality,  estimated  cost,  and  schedule. 

(1)  Are  the  contractor  sata  proposals  adequately 
proced  out? 

(2)  Do  the  contractor  estimated  data  prices  justify 
the  retention,  modification,  or  deletion  of  cited  data 
requirements? 


(3)  Is  the  use  of  contractor  formats  as  a substitute 
for  government  formats  being  considered  during  the  negotiation? 

c.  Active  Contract  Phase.  During  this  phase,  the  project 
engineer  needs  to  review  the  data  as  received  versus  the  data 
requested.  The  data's  intended  use  should  be  studied  to  deter- 
mine its  contribution  to  the  project.  The  answers  to  the 
questions  suggested  below  may  provide  a project  engineer  with 
a better  insight  into  the  data  requirements  for  follow-on 
efforts  or  projects  of  a similar  nature. 

(1)  Is  the  data  delivered  by  the  contract  received 

in  accordance  with  the  contract's  schedule  and  data  requirement 
specifications? 

(2)  Is  the  data,  as  delivered,  useful  in  satisfying 
the  cited  data  requirement? 

(3)  How  is  the  data  actually  being  used? 

(4)  Is  the  data,  as  delivered,  worth  the  price  paid 

for  it? 


(5)  Are  data  requirements  being  removed  from  contracts 
when  they  cease  to  be  valid  requirements? 


o 

Technical  Reports. 

Technical  reports  are  generally  one  of  the  most  impor- 
tant data  requirements  that  a project  engineer  will  need  in 
order  to  measure  contractor  performance  against  the  SOW 
requirements.  In  some  cases,  the  only  products  delivered 
by  the  contractor  on  an  R&D  effort  may  be  technical  reports. 
As  a result,  the  project  engineer  may  want  to  specifically 
address  the  format  and  content  requirements  for  technical 
reports  while  the  SOW  is  being  written.  The  laboratory 
personnel  serving  as  in-house  technical  report  editors  may 
provide  invaluable  assistance  in  this  area. 

The  project  engineer  may  want  to  specify  a format  for 
the  technical  report.  It  will  serve  two  possible  purposes. 
It  will  provide  contractors  with  report  construction  guid- 
ance and  minimize  the  need  for  a contractor  rewrite  of  the 
report.  Secondly,  it  may  also  help  the  project  engineer 
in  his  evaluation  of  contract  compliance.  For  cases  where 
the  technical  report  must  satisfy  the  need  of  more  than  one 
classification  of  reader,  the  body  of  the  report  should  be 
limited  to  the  main  ideas  with  appendices  used  for  detailed 
supporting  data.  An  abstract  may  be  appropriate. 

Regardless  of  the  construction  that  may  be  specified 
for  the  technical  report,  the  content  should  contain  the 
following  information: 

a.  Subject  and  Purpose  of  the  Report: 

b.  The  USAF  interest  in  the  subject  matter; 

c.  Project  Methods/Procedures  and  Results; 

d.  Contractor  Conclusions;  and 

o . Contractor  Recommendations . 
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INTRODUCTION 

In  Chapter  6 of  this  pamphlet,  recommended  checklists 
were  presented  to  assist  a project  engineer  in  conducting 
a review  of  his  statement  of  work.  However,  project 
engineer  knowledge  of  review  techniques  for  his  SOW  is  a 
separate  and  distinct  issue  from  possessing  the  ability 
to  thoroughly  review  the  SOW  content.  The  government 
personnel  helping  the  project  engineer  to  write  and  review 
the  SOW  may  only  be  contributing  from  their  own  functional 
area  perspectives.  As  a result,  the  determination  of 
whether  or  not  the  SOW  communicates  (in  a clear,  coherent, 
and  understandable  manner)  the  technical  tasks  to  be 
performed  may  be  difficult  to  evaluate. 

One  of  the  main  points  stressed  in  this  handbook  is 
that  the  SOW  should  be  written  so  as  to  preclude  the 
possibility  of  more  than  one  interpretation  of  content. 

The  question  of  contractor  interpretation  of  SOW  require- 
ments must  be  specifically  addressed  in  the  review.  As  a 
result,  the  project  engineer  should  conduct  a special 
review  to  identify  all  possible  contractor  interpretations 
of  content  and  their  impact  on  efficient  project  accomplish- 
ment. It  should  always  be  assumed  that,  given  more  than  one 
possible  SOW  interpretation,  a contractor  will  select  the 
one  that  best  suits  his  objectives. 

It  is  the  purpose  of  this  chapter  to  present  some 
general  examples  of  SOW  pitfalls  followed  by  examples  of 
potential  pitfalls  that  can  be  seen  in  some  real  world  R&D 
SOW  paragraphs,  that  is,  possible  contractor  interpretations 
and  the  consequence  thereof.  A suggested  approach  to 
remedying  pitfalls  will  also  be  presented. 

GENERAL  DISCUS  Sj,uN  OF  SOW  PITFALLS 

The  chief  trouble  spots  in  procurement  documents  are 
indefinite,  unrealistic,  restrictive,  inconsistent,  anti- 
quated and  unenforceable  requirements.  They  appear  in 
statements  of  work  quite  frequently  because  of  carelessness, 
or  just  plain  lack  of  common  sense.  In  addition  to 
contributing  to  potential  project  failure,  they  often 
result  in  ill  feelings,  extra  costs,  and  occasionally, 
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contractor  bankruptcy.  Below  are  general  examples  to 
illustrate  the  problems  that  can  be  encountered: 

a.  Indefinite  Requirements.  Those  requirements  stated 
in  such  an  incomplete  or  ambiguous  manner  that  numerous 
interpretations  are  possible.  The  following  are  12  examples 
of  indefinite  requirements . They  have  been  numbered  and 
capitalized  for  each  identification.  (For  illustration 
purposes  only,  the  item  described  is  a procurement  document 
for  sugar  cane  molasses.) 

The  molasses  should  be  prepared  in  the 
PROPER  (1)  manner  and  shall  be  as  FREE 
FROM  IMPURITIES  AS  (2)  BEST  COMMERCIAL 
PRACTICES  (3)  make  POSSIBLE  (4) . The 
molasses  shall  be  a product  obtained  in 
the  manufacture  of  cane  sugar  without 
EXCESSIVE  (5)  use  of  sulphur  or  other 
bleaching  agent.  The  finished  product 
Shall  be  of  GOOD  FLAVOR  (6)  CHARACTER- 
ISTIC (7)  of  HIGH  QUALITY  (8)  sugar 
cane  molasses  free  from  UNDESIRABLE  (9) 
taste  and  odor;  shall  be  REASONABLY  (10) 
clear;  shall  contain  no  EXCESSIVE  (11) 
sediment;  and  shall  be  PRACTICALLY  FREE 
(12)  from  dirt,  grit,  or  other  matter. 

b.  Unrealistic  Requirements . Those  requirements  that 
are  either  impossible  to  meet  or  which  raise  the  price  of 
the  item  to  an  uneconomical  level.  Inclusion  of  such 
requirements  is  one  of  industry's  chief  criticism  of  Govern- 
ment procurement  documents.  An  example  of  this  type 
problem  would  be  a procurement  document  which  is  for  peanuts 
(roasted,  salted)  and  which  established  a minimum  require- 
ment of  a 27-inch  vacuum  for  the  container  to  transport  the 
peanuts.  Commercial  equipment  can  normally  "pull"  only  25 
inches.  Few,  if  any,  manufacturers  possess  the  type  of 
equipment  to  meet  the  requirement.  To  equip  machines  to 
provide  the  extra  2 inches  would  require  excessive  special 
equipment  that  contractors  would  not  need  after  military 
orders  were  completed.  This  requirement  is,  therefore, 
unrealistic  and  unduly  increases  the  cost  of  the  product 

to  the  Government. 

c.  Restrictive  Performance  Requirements . Those 
requirements  that  unncessarily  limit  the  methods  of 
performance.  This  requirement  may  preclude  the  use  of 
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alternative  methods  which  are  better  and  sometimes  less 
costly  than  those  specified.  An  example  of  this  type 
problem  would  be  a requirement  in  a procurement  document 
stating  "the  glue  used  shall  be  an  animal  glue  conforming 
to  Federal  Specification  MMM-A-100C."  This  requirement  is 
restrictive  in  that  it  does  not  permit  the  use  of  synthetic 
glue  which  would  afford  a bond  equal  to  or  superior  to  that 
obtained  by  the  use  of  animal  glue.  Use  of  synthetic  glue 
should  be  permitted  or  the  reference  to  type  of  glue  should 
be  deleted  and  a performance  test  substituted. 

d.  Inconsistent  Requirements.  These  requirements  in 
a procurement  document  mean  the  presence  of  two  or  more 
requirements  that  are  mutally  exclusive.  That  is,  if  the 
contractor  meets  one  of  them,  he  cannot  meet  the  other.  An 
example  which  illustrates  this  type  problem  was  encountered 
in  a military  specification  for  a service  cap.  The  speci- 
fication contained  one  provision  stating  "the  braid  shall 
be  stitched  with  its  bottom  edge  located  not  more  than  1/16 
inch  above  the  center  of  the  1-inch  band."  If  this  is  done, 
the  braid  comes  right  down  to  the  bottom  edge  of  the  band 
after  the  latter  is  folded  under  along  its  center  line. 

This  requirement  was  in  conflict  with  another  provision 

of  the  same  spec_fication  which  required  "the  braid  be 
located  so  that  its  bottom  edge  is  3/16  inch  above  the 
bottom  of  the  band  in  the  finished  cap."  (The  above 
inconsistency  was  subsequently  corrected  by  deleting  the 
requirement  that  the  braid  be  stitched  to  the  center  of 
the  1-inch  band.) 

e.  Antiquated  Requirements . Those  characteristics 
that  have  been  left  behind  by  the  march  of  technological 
progress.  In  addition,  t.t  y frequently  get  introduced  as 

a result  of  a blind  application  of  the  "scissors  and  scotch 
tape"  approach  to  SOW  preparation.  Before  any  specification 
is  referenced,  it  should  be  reexamined  to  ascertain  if  it 
is  up-to-date.  An  old  specification  for  coconut  (prepared) 
was  one  of  a group  of  specifications  written  over  a decade 
ago  and  used  long  after  conditions  had  changed.  Since  the 
time  this  specification  was  written,  numerous  processes, 
such  as  frying  (desiccating) , formerly  performed  in  this 
country  are  now  being  performed  in  the  tropical  areas  where 
the  product  is  grown.  This  procedure  eliminates  the  need 
for  differentiating  between  the  types  currently  specified; 
namely,  all  domestic  processing  and  partially  domestic 
processing  since  only  one  type  can  presently  be  procured. 
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Differences  in  manufacturing  techniques  have  also  arisen, 
making  the  size  distinctions  established  in  the  specifica- 
tion currently  meaningless.  Moreover,  techniques  have  been 
adopted  by  the  trade  for  mostening  the  desiccated  coconut, 
utilizing  propylene  glycol  which  also  serves  as  a mold 
inhibitor,  thus  extending  the  storage  life  of  the  product 
considerably.  Such  practices  were  not  reflected  in  the 
old  specification. 

f.  Unenforceaole  Requirements.  Those  requirements  for 
which  it  is  difficult  or  impossible  to  perform  or  to  conduct 
inspection.  As  an  example,  a specification  for  sauce 
(Worchester shire)  established  a requirement  that  the  sauce 
be  well  cooked  and  thoroughly  ripened  in  wood  for  not  less 
than  60  days.  Since  no  end-product  test  has  been  established 
to  differentiate  between  a product  which  has  not  been 
ripened,  or  ripened  for  a shorter  period  of  time,  as 
against  a product  which  has  been  ripened  for  the  specified 
period,  an  inspector  is  obliged  either  to  witness  the 
aging  process  or  accept  the  contractor ' s certificate  that 
he  has  complied.  The  true  extent  of  this  problem  can  be 
fully  appreciated  when  the  60-day  aging  period  is  compared 
with  the  shorter  period  of  time  generally  allowed  for 
procurement  and  delivery  of  the  product. 

PITFALLS  IN  R&D  STATEMENTS  OF  WORK 

The  following  is  a sample  of  paragraphs  taken  from  R&D 
SOWs  that  were  actually  incorporated  into  contracts.  They 
all  contain  potential  pitfalls  that  can  affect  project 
resources  and  contractor  performance.  After  each  sample 
paragraph,  a discussion  of  the  potential  pitfall  will  be 
presented.  The  objective  is  to  provide  project  engineers 
with  concrete  examples  of  how  to  critically  review  an  SOW 
for  pitfalls. 

Case  Example  1 

The  contractor  shall  establish  physical  proper- 
ties and  strength  characteristics  of  the  racks 
and  cabinets  which  house  the  components.  This 
may  require  discussions  and  visits  with  the 
manufacturers,  that  is,  Lenkurt  and  WECO,  and 
may  be  subject  to  proprietary  agreements. 

Discussion 


While  it  may  be  appropriate  for  a project  engineer  to 
allow  a contractor  to  establish  physical  properties  and 
performance  characteristics,  should  there  not  be  a 
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constraint  introduced  that  the  properties  and  character- 
istics are  subject  to  government  review  and  approval? 

In  the  second  sentence,  the  word  "may"  is  used  twice  and 
two  questions  come  to  mind.  First,  how  does  the  contractor 
price  out  in  his  proposal  the  travel  expenses  associated 
with  possible  manufacturer  visits  or  should  he  not  do  so 
because  the  word  "may"  connotes  an  optional  SOW  require- 
ment? Second,  what  is  the  project  engineer  intent  of 
"and  may  be  subject  to  proprietary  agreements?"  If  the 
project  engineer  is  attempting  to  delegate  a proprietary 
information  situation  to  the  contractor,  his  project  may 
be  heading  for  a serious  cost  increase  and  potential  legal 
problems.  In  any  case,  the  wording  of  the  second  sentence 
is  such  that  a contractor  can  interpret  it  as  an  optional 
requirement  and  consequently  ignore  it.  "May"  means 
optional. 

Case  Example  2 

For  purposes  of  scoping  the  level-of-effort, 
it  is  assumed  that  six  platforms  will  be 
analyzed  using  the  computer  model. 

Discussion 

Hew  can  a contractor  scope  a level  of  effort  on  an 
assumption?  The  requirement  should  be  specific;  a definite 
number  of  platforms  should  be  subject  of  the  computer 
model  analysis. 

Case  Example  3 

The  adequacy  of  the  cabinets  or  racks  to  survive 
the  shock  motions  will  be  determined  by  the 
analysis;  however,  the  structural  and  functional 
survivability  of  the  equipment  will  be  demonstrated 
later  by  testing  under  another  contract. 

Discussion 


The  word  "adequacy"  has  no  specific  meaning.  In 
addition,  what  shock  motions  (xs  it  a level  or  a range) 
must  be  survived?  This  question  is  not  answered  in  the 
parent  SOW.  Should  the  project  engineer  separate  the  issue 
of  cabinet  or  rack  survivability  from  the  equipment's 
structural  and  functional  survivability?  Who  is  at  fault 
if  the  equipment  "fails"  when  mounted  on  the  racks  or 
installed  in  the  cabinets?  The  contractor  who  assessed  the 
rack/cabinet  suvivability,  the  equipment  manufacturer,  or 
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the  project  engineer  who  may  have  neglected  to  allow  for 
a possible  interrelationship  of  equipment  and  rack/cabinet 
survivability? 

Case  Example  4 

The  contractor  shall  specify  the  test  method  to  be 
used. 

Discussion 


Is  a government  review/approval  action  needed  for  the 

task? 


Case  Example  5 

The  government  will  provide  environment  for  each 
building  and  building  location,  which  shall  be 
reviewed  by  the  contractor. 

Discussion 


What  is  specifically  meant  by  the  word  "environment"? 
What  alternatives  does  a contractor  have  if  he  doesn't 
agree  with  the  "environment"  after  the  government  has 
provided  it? 

Case  Example  6 


The  transceiver  electronics  will  include  cir- 
cuitry necessary  to  exhibit  the  ability  to 
handle  high  rate  asynchronous  data. 

Discussion 


What  does  the  technical  jargon  "high  r£:te"  mean?  Can 
high  rate  asynchronous  data  be  given  a specific  quantitative 
value  or  range?  What  will  the  government  accept  as  "high 
rate"? 

Case  Example  7 

The  transmitter  and  receiver  electronics  will 
be  fabricated  and  delivered  in  physically 
separate  packages.  Tne  transceiver  electronics 
is  to  be  packaged  as  small  and  as  rugged  as 
possible,  consistent  with  standard  fabrication 
techniques.  It  is  desired  to  maintain  ease  of 
servicing,  reliability,  performance  and  low 
cost,  in  reasonably  small,  rugged  packages. 
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Discussion 


Just  how  important  of  a technical  requirement  is  the 
issue  of  the  size  and  durability  of  packaging?  Is  it  a 
design  goal?  If  so,  how  crucial  is  it?  How  much  time 
and  resources  should  a contract  dedicate  to  it?  What  is 
meant  by  "standard  fabrication  techniques"?  Will  they 
suffice  for  this  project? 

Case  Example  8 

All  contract  residuals  will  also  be  delivered 
to  the  laboratory.  Acceptance  tests  will  be 
made  at  the  systems  contractor's  facility. 

Support  equipment  must  be  specified  early  to 
both  the  Air  Force  and  the  systems  contractor. 

Discussion 


What  is  the  relationship  between  sentences  in  this 
paragraph?  Should  they  not  be  made  separate  paragraphs? 

What  will  receive  acceptance  testing?  Clearly  not  the 
contract  residuals. 

Case  Example  9 

SCOPE;  This  program  includes  work  to  be 
performed  at  both  the  contractor's  plant 
and  at  Air  Force  Laboratory  facilities. 

The  effort  shall  specifically  include  the 
work  described  in  paragraph  4.0  Technical 
Requirements/Tasks  (and  may  include  other 
related  work  as  required  to  meet  the  overall 
contract  requirements  provided  that  such 
related  work  is  within  the  requirements  and 
resource  limitations  of  the  contract) . 

Discussion 

What  is  the  project  engineer  intent  for  the  portion  of 
the  paragraph  in  parenthesis?  The  contractor  can  ignore  it 
because  may  means  optional.  If  the  other  related  work  actually 
becomes  necessary,  will  the  contractor  contend  it  is  outside 
the  scope  of  the  contract  and  insist  on  supplementary  funding 
or  renegotiation?  The  paragraph  appears  to  imply  that  the 
effort  has  no  definite  scope.  If  this  is  true,  is  it  wise  to 
go  out  on  contract  at  this  time  with  a scope  of  such  a nature? 
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Case  Example  10 

Technical  Requirements  - Analysis,  evaluation 
and  "investigation  m the  technology  of  offen- 
sive gun-fire  control  systems  are  required. 

Although  the  effort  required  is  primarily 
reduction,  analysis,  and  interpretation  of 
test  data,  (some  effort  may  be  required  in 
investigations  in  areas  such  as)  cross-wind 
ballistics,  kinematic  prediction,  closed- 
loop  trainable  gun  concepts,  electro-optical 
and  infrared  trackers,  bullet  tracking 
concepts,  and  system  mechanizations.  Thus 
two  types  of  tasks  are  required  - those 
dealing  with  evaluation  support  (some  of 
which  will  require  quick  response) , and 
those  dealing  with  investigations  of  the 
state-of-the-art  of  gun  fire  control  systems. 

Discussion 

In  sentence  two,  there  is  a listing  of  very  specific  areas 
for  contractor  investigation.  However,  the  expression  in  paren- 
thesis is  vague  and  may  be  interpreted  by  the  contractor  as  non- 
mandatory. Is  this  really  what  the  project  engineer  intended? 

The  second  sentence  should  be  specially  scoped  and  made  mandatory. 
An  alternative  would  be  to  rewrite  the  sentence  and  specify  that 
the  investigations  are  a separate  option  for  the  effort.  Then 
the  contractor  could  write  a specific  technical  and  cost  proposal 
for  the  option  and  the  project  engineer  could  elect  to  include 
or  delete  the  option  from  the  contract. 

Case  Example  11 

No  reliability  testing  program  need  be 
undertaken  as  a part  of  this  program. 

However,  an  effort  should  be  made  to 
build  hardware  that  will  demonstrate 
tracking  and  pointing  under  laboratory 
conditions  for  reasonable  periods  of 
time  without  equipment  failure. 

Discussion 

The  paragraph  tells  the  contractor  that  no  formal 
reliability  testing  program  is  required  for  the  project. 

However,  what  constitutes  "reasonable  periods  of  time  with- 
out equipment  failure"?  This  expression  should  be  clarified 
or  deleted.  Otherwise,  how  can  contractor  compliance  be 
measured? 
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Case  Example  12 


In  the  conduct  of  the  design  and  installation 
of  the  pallets;  equipment,  antennas,  and 
associated  cabling  a system  safety  analysis 
shall  be  performed  and  documented.  These 
system  safety  studies  will  be  based  on  sound, 
practical  engineering  judgment,  experience 
and  available  data.  No  complete  system  safety 
program  will  be  undertaken  as  part  of  this 
evaluation.  The  prime  objectives  of  the  study 
are  to  minimize  unintentional  catastrophic 
accidents  causing  physical  harm  to  uninvolved 
bystanders  or  the  flight  crew.  Paragraph 
5. 8. 2.1  of  MIL-STD-882  contains  a list  of 
possible  hazards  that  should  be  considered. 

Discussion 


Systems  safety  is  too  important  of  an  operational  USAF 
concern  to  be  so  vague  about.  Has  the  project  engineer  properly 
addressed  the  issue  by  requiring  that  safety  studies  be  based 
on  sound  practical  engineering  judgment  and  experience?  This 
requirement  is  too  abstract  and  provides  the  contractor 
virtually  no  guidance  whatsoever.  In  addition,  what  is  an 
"unintentional  catastrophic  accident"  and  how  far  does  the 
envelope  of  "uninvolved  bystanders"  extend?  Finally,  there  is 
no  way  to  measure  whether  or  not  a contractor  has  considered 
the  potential  hazard  in  MIL-STD-882.  Is  hazard  consideration 
a contractor  intellectual  process  or  a specific  contractor 
activity?  The  intent  is  very  ambiguous.  In  summary,  the 
project  engineer  may  not  have  said  what  he  means  in  this  para- 
graph and  contractor  performance  may  be  impossible  as  a 
result. 

Case  Example  13 

SCHEDULING:  Scheduling  of  calibration  and 

installation  services  is  uncertain  at  this 
time  due  to  the  nature  of  the  field  test. 

Installation  and  field  test  of  the  system 
at  Cloudcroft,  New  Mexico  will  occur  when 
the  schedule  of  operations  at  the  Electro- 
Optical  Surveillance  Research  Site  permits. 

It  is  anticipated  that  this  will  not  occur 
before  1 February  1973  or  after  30  June  1973. 

Calibration  of  the  system  at  the  contractor's 
facility  shall  occur  immediately  before  the 
field  test. 


! 
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Installation  and  field  test  of  the  system 
at  the  Electro-Optical  Surveillance  Research 
facility  requires  eight  man  weeks  of  con- 
tractor effort  at  the  site.  The  contractor 
will  be  notified  at  least  15  days  in  advance 
of  the  start  of  this  effort. 

Discussion 


What  are  the  resource  implications  of  tieing  up  a con- 
tractor's technical  service  test  personnel  for  a test  program 
with  such  an  uncertain  schedule?  The  contractor  may  charge 
the  government  for  the  opportunity  cost  associated  with  holding 
his  test  personnel  on  a 15- day  "alert"  status. 

Case  Example  14 

The  contractor  shall  supply  an  FAA  Certified 
DC9-30F  type  aircraft  and  FAA  Certified  crew. 

A minimum  of  90  flight  hours  shall  be  supplied 
with  at  least  half  of  those  required  for  on 
station  tests . 

Discussion 


What  is  meant  by  the  word  "supply"  in  the  first  sentence? 

Is  the  contractor  to  buy,  lease,  or  provision  an  FAA  Certified 
DC9-30F  type  aircraft  and  FAA  Certified  crew?  The  most  reason- 
able intent  appears  to  be  the  leasing  of  an  aircraft  and  the 
hiring  of  an  aircrew.  Has  the  cheaper  alternative  been  pursued, 
that  is,  the  use  of  a USAF  test  aircraft  and  aircrew? 

Case  Example  15 

The  contractor  shall  consider  the  flight 
test  requirements  and  objectives  for  flight 
testing  the  Radiant  system  as  outlined  in 
the  Test  Plan  generated  by  the  8795th  Test 
Wing. 

The  contractor  shall  consider  all  system 
configuration  requirements  of  the  Radiant 
System  and  associated  equipment  required 
for  the  flight  test.  Attached  to  this 
statement  of  work  is  an  equipment  list, 
including  each  individual  unit's  size, 
weight,  and  power  requirements  and 
installation  drawings  made  by  the  XYZ 
Corporation. 
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The  antenna  configuration  requires 
two  E/F  band  omni  antennas  to  be 
mounted  underneath  the  fuselage.  A 
separation  of  15  feet  or  better  is 
acceptable. 

The  contractor  shall  consider  all  logistics 
required  to  assure  proper  and  timely  test 
support  with  the  Podunk  Air  Base  and  the 
FAA.  Most  flights  will  occur  after  10  p.m. 
and  last  for  3 to  4 hours  five  days  a week 
and  possibly  on  weekends. 

The  contractor  shall  consider  doing  data 
reduction  and  writing  a flight  test  report 
if  the  8795th  is  unable  to  support  this 
effort.  This  will  require  several  trips 
to  Podunk  and  meetings  with  the  8795th 
people  who  had  been  involved  in  the  data 
analysis  to  completely  understand  what  is 
required. 

Discussion 


As  a result  of  these  SOW  paragraphs,  the  contractor  shall 
clearly  be  required  to  consider  a large  number  of  tasks.  But, 
what  is  meant  by  "consider",  is  consideration  enough,  and  how 
does  the  project  engineer  propose  to  measure  the  contractor's 
ability  to  "consider"?  If  contractor  performance  is  mandatory, 
the  project  engineer  should  specifically  say  so.  If  he  waits 
until  after  contract  award,  the  probability  of  project  failure 
and  legal  litigations  due  to  semantics  will  be  exceptionally 
high.  One  final  point.  What  does  the  project  engineer  really 
mean  by  the  word  "logistics"  in  the  fourth  paragraph?  For 
what  specifically  is  he  asking? 

Case  Example  16 

a.  Provide  analysis  and  evaluation 
support  to  Laboratory  A in  areas 
associated  with  gun  fire  control. 

This  support  will  be  provided  at  the 
request  of  the  Laboratory  A in  areas 
which  may  include  but  will  not  be 
limited  to  the  following: 

(1)  Aid  in  the  planning  and 
execution  of  flight  tests  such 
as  the  impending  tests  of  the 
ATS  and  the  comparative  gunsight 
evaluation  flight  test. 
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(2)  Provide  data  reduction, 
analysis,  and  interpretation 
of  flight  test  data. 


(3)  Assist  Laboratory  A in 
evaluation  of  the  design  and  . 
implementation  of  experimental 
target  tracking  systems  such 

as  the  Augmented  Tracker  System 
(ATS)  in  technical  areas  where 
in-house  expertise  is  not 
available. 

(4)  Provide  support  in  the 
generation  and  validation  of 
software  for  ballistics  and 
kinematic  prediction  when  not 
available  from  Laboratory  A 
in-house  analysis. 

(5)  Aid  in  establishing 
requirements  for  ballistics 
efforts  applicable  to  gun 
fire  control  system  design. 
Laboratory  A will  submit  the 
requirements  to  Laboratory  B 
for  resolution. 


(6)  Provide  support  for 
evaluation  of  unique  problems 
as  assigned  by  Laboratory  A, 
such  support  being  limited  to 
constraints  imposed  by  time 
and  fiscal  resources. 


b.  Perform  investigations  and 
experiments  in  gun  fire  control  as 
assigned  by  Laboratory  A in  the  areas 
listed  above.  Tasks  under  this  item 
11  be  conducted  as  time  permits, 
since  paragraph  a is  to  be  considered 
as  the  major  task  under  this  contract. 

Discussion 

The  paragraphs  presented  in  this  last  case  example  are 
possibly  a good  illustration  of  inconsistent  SOW  requirements 
compounded  by  the  presence  of  very  permissive  loopholes.  Para- 
graph b informs  the  contractor  to  consider  paragraph  a as  the 
major  contractual  task.  If  thi  > is  the  case,  why  is  the  word 
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"may"  used  in  the  second  sentence  of  paragraph  a?  Should  the 
wcrd  "shall”  be  substituted  in  place  of  "may"?  Now  let's  take 
a look  at  the  possible  reasons  for  including  the  expression 
"but  will  not  be  limited  to".  Was  it  the  project  engineer's 
intention  to  include  the  expression  in  order  to  stimulate  the 
introduction  of  the  contractor's  creative  effort  into  the 
contract?  Alternatively,  was  "but  not  limited  to"  used  to 
provide  the  project  engineer  a loophole  to  compensate  for  the 
fact  that  he  cannot  identify  all  the  tasks  that  need  to  be 
pursued  by  the  contractor?  Will  the  contractor  consider  the 
expression  as  the  imposition  of  a requirement  that  allows  the 
project  engineer  to  add  tasks  during  the  contract  performance 
without  the  necessity  of  receiving  contractor  concurrence? 

This  question  may  be  a serious  concern  for  a contractor  if 
the  contract  awarded  to  him  is  of  the  fixed  price  type. 
Contractor  objections  may  not  be  very  strong  if  the  contract 
contemplated  is  the  cost  plus  type.  As  a matter  of  fact,  a 
contractor  can  turn  the  expression  "but  not  limited  to"  around 
to  his  own  advantage.  He  may  try  to  interpret  into  the 
expression  the  prerogative  to  introduce  additional  tasks  at 
his  own  discretion  without  government  approval.  The  dangers 
of  using  such  language  in  a SOW  should,  by  this  point,  be 
rather  obvious.  Clearly  the  project  engineer,  the  contractor, 
or  both  parties  can  be  hurt  by  such  phrasing.  But,  more 
important,  it  can  almost  be  guaranteed  that  the  project  will 
definitely  suffer  the  consequences. 


REMEDIES 

The  reader  may  feel  that  the  discussions  of  the  sixteen 
case  examples  just  presented  may  be  a bit  extreme.  But,  SOW 
misinterpretations  generate  extreme  positions  between  a project 
engineer  and  his  contractor  during  the  life  of  a contract. 

Very  drastic  project  consequences  do  result. 


The  culpability  for  SOW  misinterpretations  and  the 
consequences  thereof  cannot  always  be  assigned  to  the  contractor. 
The  project  engineer  may  be  his  own  worst  project  enemy.  His 
pencil  may  be  leading  his  mind  while  he  is  writing  the  SOW. 
Unless  he  can  become  his  own  worst  critic  with  regard  to  his 
SOW  and  the  meaning  of  its  content,  he  may  experience  problem 
after  problem  with  his  R&D  contract.  What  remedies  can  he 
pursue  prior  to  contract  award  and  completely  avoid  the 
problem? 
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The  following  guidance  is  proposed  to  assist  a project 
engineer  in  his  efforts  to  avoid  pitfalls  from  being  incor- 
porated into  his  contract: 

a.  Be  completely  knowledgeable  about  all  of  the  aspects 
of  your  project  with  specific  attention  being  given  to  what 
you  want  to  accomplish  in  your  SOW. 

b.  Write  what  you  mean  and  mean  what  you  write.  Don't 
let  semantics  kill  your  project! 

c.  Never  assume  that  the  contractor  understanding  of 
the  real  meaning  of  SOW  requirements  can  be  relied  upon  to 
circumvent  pitfalls  in  your  SOW. 

d.  Be  your  own  worst  devil's  advocate.  Make  a deliberate 
effort  to  locate  and  correct  any  conceivable  misinterpretation 
or  pitfall  in  your  SOW  before  it  is  incorporated  into  the  RFP. 

e.  Actively  encourage  all  preparation  and  review 
participants  to  give  your  SOW  a thorough,  critical  review 
before  it  is  sent  to  prospective  contractors  for  technical 
proposal  consideration/preparation . 

f.  Assume  a contractor's  perspective  and  re-read  your 
statement  of  work  from  that  viewpoint.  Assess  the  probability 
of  semantic  difficulties  and  pitfall  occurrence  and  their 
possible  impact  on  project  accomplishment.  Integrate  the 
results  of  this  evaluation  into  the  output  from  the  preceding 
two  paragraphs. 

g.  Never  be  hesitant  to  revise  your  SOW  prior  to  contract 
award.  It  is  better  to  be  active  in  anticipation  of  problems 
than  reactive  as  a result  of  problems. 

h.  Establish  an  SOW  pitfall  paragraph  file  from  your  own 
experience  and  those  of  co-workers.  Document  the  pitfall  and 
its  impact  on  previous  contractual  efforts.  Then  use  this 
folder  as  a guide  when  you  are  trying  to  detect,  correct,  and 
avoid  pitfalls  on  all  future  efforts. 

i.  Don't  loose  sight  of  the  facts  that: 

(1)  Contractors  may  take  a literal  interpretation  of 
SOW  content,  and 

(2)  Given  a choice  of  possible  SOW  interpretations, 

a contractor  will  normally  lean  toward  selecting  the  interpretation 
that  gives  him  the  maximum  possible  advantage. 
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CHAPTER  8 


THE  LEGAL  IMPLICATIONS  OF  THE  STATEMENT  OF  WORK 


INTRODUCTION 

This  chapter  covers  in  moderate  detail  the  more  important 
legal  aspects  of  specifications/statements  of  work  and  their 
impact  on  government.  It  is  extracted  from  Chapter  8,  Speci- 
fications and  Statements  of  Work  of  the  3rd  Edition  of 
Government  Contract  Law  published  by  the  Air  Force  Institute 
of  Technology,  School  of  Systems  and  Logistics,  Wright- 
Patterson  Air  Force  Base,  Ohio.  The  purpose  of  incorporating 
this  material  into  the  pamphlet  is  to  provide  a project  engineer 
with  a sample  of  the  ways  in  which  the  legal  community  can 
interpret  SOW  requirements  and  the  rules  pertaining  to  SOW  or 
specification  interpretation. 

The  work  statement,  specifications,  drawings,  and  item 
description  formulate  the  very  heart  of  any  procurement. 

Whether  or  not  a contract  will  be  successfully  performed  is 
quite  often  determined,  not  at  the  time  the  contract  is 
negotiated  or  the  award  is  made,  but  rather  at  the  time  the 
purchase  or  performance  description  is  written.  The  need  for 
clarity  and  preciseness  of  expression  is  perhaps  greater  in 
contracts  than  in  any  other  form  of  communication.  The  extent 
to  which  this  is  or  is  not  accomplished  will  have  a direct 
bearing  on  the  ultimate  outcome  of  a contract.  The  greatest 
care,  therefore,  is  required  in  formulating  descriptions  of 
desired  products  or  services.  A job  well  done  results  in 
savings  in  time,  money,  effort  and  administrative  headaches. 

DEFINITION  OF  SPECIFICATIONS 

Before  any  invitation  for  bids  or  request  for  proposals 
can  be  used  or  any  contract  entered  into,  it  is  necessary  to 
define  the  item  or  service  that  is  to  be  the  subject  of  the 
invitation,  proposal  or  contract.  The  definitive  or  descrip- 
tive words  identifying  the  subject  matter  are  called  speci- 
fications. Identification  of  the  subject  matter  is  the  heart 
of  each  procurement  and  it  is  the  basis  upon  which  bids  are 
made,  proposals  offered,  negotiations  concluded  and  contracts 
entered.  The  use  of  specifications  accomplishes  two  purposes; 
(1)  the  specifications  of  requirements  for  an  item,  material, 
process  or  service,  and  its  preservation,  packaging,  packing 
and  marking;  and  (2)  the  establishment  of  criteria  bywhich  the 
government  can  determine  whether  or  not  contract  requirements 
have  been  met. 
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SPECIFICATION  CATEGORIES 

a.  Minimum  Acceptable  Description.  The  minimum  acceptable 
purchase  description  is  the  identification  of  a requirement  by 
use  of  a brand  name  followed  by  the  words  "or  equal . " This  is 
used  only  as  a last  resort  when  a more  detailed  description 
cannot  be  made  available  in  the  time  for  the  procurement  at 
hand,  and,  when  more  than  one  brand  is  indicated.  The  words 
"or  equal"  are  not  added  when  only  a particular  sole  source 
producer  will  meet  the  essential  needs  of  the  government. 

b.  Design  Specification.  A design  specification  spells 
out,  in  detail,  the  materials  to  be  used,  their  sizes  and 
shapes,  and  how  the  item  is  to  be  fabricated  and  built.  It 
provides  a completely  defined  item,  capable  of  manufacture  by 
a competent  manufacturer  in  the  industry. 

c.  Performance  Specification.  Performance  specifications 
express  requirements  in  such  terms  as  capacity,  function,  or 
operation  of  equipments.  In  this  type  of  specification  the 
details  of  design,  fabrication,  and  internal  structure  are  left 
to  the  option  of  the  contractor,  except  that  certain  features 
or  parts  may  specifically  be  required. 

d.  Mixed  Specification.  Rarely  does  the  government  use 
a pure  form-  of  either  type  of  specification.  Practically 
speaking,  rarely  is  a specification  either  a 100  percent  design 
specification  on  one  hand,  or  completely  a performance  speci- 
fication on  the  other.  Actually,  nearly  every  specification 
contains  some  elements  of  both  types.  Characterization  of  a 
specification  as  "design"  or  "performance,"  therefore,  merely 
reflects  which  category  predominates.  Whatever  kind  of  speci- 
fication may  be  used  in  a procurement,  including  plans,  drawings, 
or  purchase  descriptions,  it  is  made  available  to  all  potential 
suppliers.  This  procedure  is  an  important  element  in  the  basic 
specification  policy  of  the  government. 

SPECIFICATIONS  POLICY 

Department  of  Defense  specifications  policy  is  twofold: 

(1)  to  state  only  actual  minimum  need  and  (2)  to  describe  need 
so  as  to  stimulate  maximum  competition.  The  first  precept 
seems  self-explanatory.  It  means  that  the  specification  must 
describe  what  is  needed,  not  what  may  be  desired.  The  second 
precept  is  to  use  the  kind  of  specification  which  will  generate 
maximum  competition.  There  are  occasions  when  the  use  of  a 
design  specification  will  accomplish  this  result  as,  for  example, 
where  the  item  was  developed  for  the  government  and  can  be 
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exactly  reproduced  by  any  capable  manufacturer  without  further 
development.  On  other  occasions,  the  use  of  performance  speci- 
fications may  better  assure  competition  being  obtained  as,  for 
example,  where  the  government  requirement  can  be  met  by  any  one 
of  a number  of  commercially  designed  and  available  products. 

But,  as  we  noted  earlier,  there  are  some  instances  when  competition 
is  just  not  available.  An  example  would  be  where  only  one  source 
exists. 

Some  products,  such  as  specialized  military  electronic 
equipment,  are  not  available  on  the  commercial  market.  Such 
equipment  is  especially  developed  and  designed  for  military 
use,  frequently  a time-consuming  process.  Thereafter,  when 
the  government  wishes  to  buy  such  equipment  in  quantity,  a 
design  specification  is  used  to  tell  prospective  contractors 
precisely  how  the  item  should  be  made.  This  makes  it  possible 
to  avoid  duplication  of  development  time,  theoretically  permits 
wide  competition  by  firms  which  do  not  have  the  scientific  or 
engineering  staffs  to  do  the  development,  and  results  in  the 
delivery  to  the  government  of  relatively  standardized  equipment 
from  various  suppliers. 

On  the  other  hand,  many  items  of  equipment,  such  as  tractors, 
earth-moving  equipment,  laundry  equipment,  etc.,  are  available 
on  the  commercial  market.  Such  items  are  commercially  designed 
and  each  manufacturer's  design  differs  markedly  from  his  com- 
petitor's. Each  manufacturer  is  tooled  up  to  make  equipment  to 
his  own  design  and  it  would  be  very  expensive  to  require  him  to 
construct  equipment  to  some  competitor’s  or  to  government  design. 

In  these  cases,  the  government  uses  performance  specifications 
so  that  competition  can  be  obtained  from  every  firm  which 
regularly  makes  a suitable  commercial  product.  Such  a specifica- 
tion fosters  competition  and  avoids  the  favoritism  which  would 
occur  by  the  adoption  of  one  company's  design  or  a government 
design  which  was  more  nearly  like  the  design  of  one  company 
than  of  others.  Such  a specification  also  avoids  special 
retooling  and  production  starting  costs  and,  hence,  results 
in  lower  prices  to  the  government. 

Performance  specifications  are  frequently  used  when  no 
suitable  commercial  item  is  available  and  when  there  is  no 
standardized  government  design.  In  such  cases,  where,  in  the 
opinion  of  the  buying  activity,  the  design  problem  is  well 
within  the  capabilities  of  a number  of  competent  firms  having 
design  staffs,  purchase  will  be  made  against  a performance 
specification  and  the  design  details  left:  to  the  contractor. 

In  this  way,  ifc  is  possible  to  get  competition  for  items  of 
specialized  military  usage,  but  such  competition  is  necessarily 
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confined  to  firms  which  are  competent  to  design  and  build 
equipment  meeting  the  military  performance  requirement.  It 
is  also  obvious  that  research  and  development  contracts  are 
performed  against  what  are  basically  performance  specifications. 

PRINCIPLES  RELATING  TO  SPECIFICATIONS 

a.  Contract  Must  Be  Read  In  Its  Entirety.  It  is  a 
basic  tenet  of  law  that  a contract  must  be  read  as  a whole, 
and  in  its  entirety.  It  is  equally  elementary  that  meaning 
must,  if  possible,  be  given  to  all  language  employed.  An 
accepted  rule  of  interpretation  is  that  no  word  in  a contract 
is  to  be  rejected  or  treated  as  a redundancy,  or  as  meaning- 
less, if  any  meaning  which  is  reasonable  and  consistent  with 
the  other  parts  can  be  given  to  it,  or  if  the  contract  is 
capable  of  being  construed  with  the  word  or  words  left  in. 

Thus,  in  determining  the  responsibilities  of  the  con- 
tracting parties,  and  the  performance  that  may  be  demanded 
of  a contractor,  a review  solely  of  the  "statement  of  work" 
or  item  description  is  not  sufficient.  In  accordance  with 
this  rule,  all  parts  of  the  contract  should  be  read  and 
considered  in  determining  what  is  required. 

"All  parts  of  the  contract"  includes  not  only  the 
contract  document  itself,  but  also  matters  referenced  or 
incorporated  by  reference.  This,  of  course,  includes  any 
referenced  specifications  and  drawings  even  if  they  are  not 
recited  "in  toto"  in  the  contract  document  or  appended  thereto. 

b.  Right  to  Regu-1  e Compliance.  Generally,  a contract 
party  has  the  right  to  strict  compliance  with  the  specifica- 
tions by  the  other  party.  Therefore,  a contractor  who  deviates 
from  the  specifications  as  written  does  so  at  his  peril. 

However,  where  the  government,  as  a result  of  mininter- 
pretation  of  the  provisions  of  the  contract,  requires  a 
contractor  to  perform  work  not  called  for  under  its  terms, 
the  order  to  perform  is  a "change  order"  entitling  the  con- 
tractor to  an  equitable  adjustment  in  price  in  accordance 
with  the  "clause"  in  the  contract. 

c.  Ambiguities.  If  the  contract  is  considered  to  be 
ambiguous,  the  ambiguity  must  be  construed  against  the  drafter 
of  the  language.  This  too  is  a fundamental  legal  principle 
and  is  equally  applicable  to  the  government  as  well  as  the 
contractor.  Thus,  if  the  government  is  the  "drafter,"  any 
ambiguities  will  be  construed  against  the  fovernment.  Obvious 
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ambiguity,  however,  places  on  the  other  party  a duty  to 
seek  clarification.  Failure  to  do  so  will  undermine  later 
claims  based  on  the  ambiguous  language. 


d.  Presumption  of  Adequacy  of  Government  Specifications. 
Where  the  government  furnishes  design  specifications  which 
control  work  under  the  contract  there  is  a presumption  that 
the  specifications  are  adequate  for  the  purposes  intended  and 
that  if  followed  the  desired  result  will  be  obtained.  There 
is,  in  effect,  an  "implied  warranty"  that  the  specifications 
are  adequate. 

e.  Effect  of  Contractor’s  Knowledge  of  Defective  Speci- 
fications" The  precedent  is  also  well  established  that  where 
a contractor  is  required  to  proceed  under  specifications  which 
are  defective  or  incomplete  or  which  make  the  contract  impos- 
sible to  perform,  such  situations  form  a basis  for  price 
adjustment  under  the  "Changes"  clause,  together  with  necessary 
time  extensions  to  delivery  schedules,  even  though  the 
unattainable  requirement  is  ultimately  relaxed  to  permit 
performance. 


however,  if  the  contractor  knows,  or  perhaps  from  his 
( rience  shoald  know,  that  the  desired  result  cannot  be 
-ine.'  . he  cannot  make  a useless  thing  and  expect  to  be 
.'hxe  to  charge  for  it.  Where  the  contractor  knows,  or  should 
’.ave  known,  that  the  specifications  are  defective  he  is  under 
a duty  to  apprise  the  government  of  this.  He  discharges  his 
obligation  by  making  the  defect  known  to  the  government.  The 
government  then  has  a duty  to  act.  Additionally,  where  speci- 
fications are  defective  on  their  face,  or  obviously  unsuitable, 
the  contractor  has  a duty  to  inquire;  if  he  fails  to  so  inquire 
he  cannot  successfully  advance  a claim  of  excusabrlity. 

f.  Workmanlike  Performance.  Strict  compliance  with  the 
specifications  is  not  the  contractor’s  only  responsibility. 

He  is  also  under  a basic  duty  to  perform  in  the  best  and  most 
workmanlike  manner.  This  requires  a performance  standard 
equal  to  that  of  a qualified,  careful  and  efficient  person 
performing  similar  work.  This  is  so,  even  if  the  standard  is 
not  set  forth  in  the  contract.  When  the  contract  does  not 
contain  detailed  specifications  a test  of  "skillful  and 
workmanlike"  performance  is  good  industry  practice. 

g.  Order  of  Preference.  Sometimes  conflicts  appear 
between  the  basic  contract  and  the  specifications  or  drawings, 
or  between  the  specifications  and  drawings.  Generally  speaking, 
when  there  is  a conflict  between  the  contract  and  the  specifications 
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or  drawings,  the  terms  of  the  contract  will  prevail;  if 
the  conflict  exists  between  the  specification  and  drawings, 
the  specifications  will  prevail.  However,  if  the  document 
of  precedence  is  silent  on  the  matter  and  the  matter  is  not 
in  conflict  with  some  other  provision,  the  "let  cer"  document 
will  prevail.  For  example,  if  the  drawings  provide  for 
something  which  is  not  in  the  specification,  and  it  is  not 
in  conflict  with  the  specifications  or  the  basic  contract 
document,  the  drawing  would  prevail  to  that  extent.  This 
is  necessarily  so  under  the  rule  above,  that  the  contract 
must  be  read  as  a whole. 

h.  Impossibility  of  Performance.  Generally,  when  a 
contractor  undertakes  to  perform  under  a performance  speci- 
fication he  generally  assumes  the  risk  that  he  can,  in  fact, 
accomplish  the  end  result.  When  he  agrees  to  so  perform,  it 
is  presumed  that  he  knows  the  '•  state-of-the-art . Further- 
more, the  parties  are  presumed  to  have  entered  into  the 
contract  in  the  belief  that  the  state-of-the-art  was  such 
that  performance  was  possible. 

When  performance  requirements  cannot  be  met,  contractors, 
on  occasion,  advance  the  argument  that  the  specifications 
were  impossible  of  performance.  Generally,  when  the  perform- 
ance specifications  are  those  of  the  government  and  are 
impossible  to  perform,  the  contractor  will  be  relieved  of 
compliance. 

The  real  question  in  issue  in  these  instances  is  whether 
the  level  of  performance  called  for  is  beyond  the  reach  of 
any  contractor  in  the  field  or  is  merely  beyond  the  capability 
of  the  contractor  concerned.  If  the  latter,  an  impossibility 
of  performance  situation  would  not  exist.  When  the  contractor 
is  a leader  in  its  field,  the  argument  of  "impossibility"  is 
considerably  weakened  and  the  position  much  more  difficult 
to  maintain. 

i.  Alternate  Methods  of  Performance.  Where  alternate 
methods  of  performance  are  permitted  by  the  specifications, 
the  contractor  has  the  freedom  of  choice.  However,  if  one 
method  is  either  impossible  to  perform,  illegal,  or  more 
costly,  the  contractor  is  expected  to  follow  the  other  method. 
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GENERAL  RULES  APPLICABLE  TO  PERFORMANCE  UNDER  SPECIFICATIONS 


The  following  are  general  rules  applied  to  questions 
involving  performance  and  specifications.  It  should  be  noted 
that  individual  circumstances  can  alter  their  application. 

a.  When  the  government  provides  complete  design  infor- 
mation there  is  an  implied  warranty  that  an  acceptable  product 
will  result  if  specifications  are  met. 

b.  If  frustration  is  encountered  in  determining  the 
meaning  of  conflicting  or  ambiguous  specifications,  interpre- 
tation will  be  in  favor  of  the  contractor  if  the  language  was 
written  by  the  government. 

c.  The  government  is  entitled  to  strict  compliance  with 
quantitative  specifications  although  substantial  compliance 
may  be  held  to  be  sufficient  (for  example,  2,000  rpm)  . 

d.  Qualitative  specifications  are  interpreted  in  the 
light  of  custom  and  usage  in  the  particular  trade  or  profession 
(for  example,  watertight) . 

e.  Process  information  supplied  by  the  government  on  a 
permissive  or  information  basis  does  not  warrant  commercial 
practicability. 

f.  If  a contractor's  proposal  is  included  as  a part  of 
the  specifications,  there  is  a possibility  that  the  contractor 
may  be  held  to  the  performance  suggested  by  the  proposal 
(technical  message  as  opposed  uu  marketing  message) 

g.  A contractor  may  not  sit  back  and  rely  on  a patent 
ambiguity  in  specifications  and  then  demand  a compensable 
change.  He  has  an  obligation  to  address  such  ambiguity  to 
the  attention  of  the  contracting  officer  prior  to  bid 
submission. 

h.  Requiring  either  a greater  or  lesser  performance 
than  called  for  by  contract  is  a "constructive  change" 
entitling  the  contractor  to  an  equitable  adjustment  under 
the  Changes  clause. 

i.  Research  and  development  contracts  usually  do  not 
contain  design  specifications  since  the  contractor  is  generally 
required  to  design  and  build  the  item  to  meet  performance 
specifications . 
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j . In  the  event  of  a discrepancy  between  design  speci- 
fications and  performance  specifications,  the  performai."*5 
specifications  generally  control. 

k.  Most  contracts  provide  that  in  addition  to  what  is 
shown  on  the  plans  and  what  is  spelled  out  in  the  specifica- 
tions, the  contractor  shall  be  compelled  to  furnish  and  do 
whatever  is  necessary  to  provide  a complete  system  or  do  a 
complete  job.  The  test  used  is  what  should  a reasonable 
contractor  deduce  from  the  plans  and  specifications. 

l.  Where  the  language  of  the  specification  is  indefinite, 
ambiguous,  or  of  doubtful  construction,  the  practical  inter- 
pretation of  the  parties,  as  evidenced  by  usage  or  course  of 
dealing,  controls. 

CONCLUSION 

If  this  chapter  has  developed  in  the  project  engineer's 
mind  a concern  for  the  legal  implications  and  problems  that 
a statement  of  work  can  precipitate,  it  has  achieved  its 
purpose.  A project  engineer  who  keeps  the  legal  considerations 
in  mind  while  he  is  writing  the  SOW  has  taken  the  proper  ini- 
tiative needed  to  preclude  legal  problems  for  his  project 
during  the  life  of  the  contract.  However,  a word  of  caution 
is  appropriate  here.  A project  engineer  should  avoid  assuming 
the  legal  procurement  role  for  his  project.  The  legal  con- 
sequences could  be  disastrous.  Neither  the  contents  of  the 
chapter  nor  years  of  R&D  contract  management  experience  will 
prepare  a project  engineer  for  assuming  this  expertise.  He 
had  better  actively  seek  out  the  advice  and  assistance  of  the 
procurement  and  legal  personnel.  It  is  needed  to  evaluate 
the  legal  implications  and  the  potential  legal  problem  areas 
that  he  may  be  inadvertently  including  in  his  statement  of 
work  before  it  is  ever  awarded  for  performance  to  a contractor. 
He  should  additionally  return  promptly  to  the  same  personnel 
when  it  appears  that  potential  legal  problems  are  developing 
on  his  contract.  Remember  "The  lawyer  who  represents  himself 
has  a fool  for  a client." 


CHAPTER  9 


POST  STATEMENT  OF  WORK  CONSIDERATIONS 


INTRODUCTION 

With  the  completion  of  a quality  statement  of  work  that 
has  received  the  approval  of  all  the  personnel  in  the  SOW 
coordination  cycle  and  the  procurement/legal  review  process, 
the  project  engineer  has  essentially  completed  the  most  impor- 
tant task  in  the  array  of  precontractual  considerations  for 
his  R&D  project.  It  is  the  purpose  of  this  last  chapter  to 
' identify  some  points  to  be  pursued  by  the  project  engineer 

to  assure  the  receipt  of  quality  technical  proposals  from 
industry  in  response  to  his  statement  of  work. 

PURCHASE  REQUEST  (PR)  PACKAGE  DOCUMENTATION 

The  statement  of  work  is  only  one  element  in  the  document 
which  the  project  engineer  sends  to  procurement  in  order  to 
obtain  technical  proposals  from  industry  for  his  R&D  effort. 
This  document,  called  a Purchase  Request  (PR)  Package,  will 
, normally  contain  a number  of  other  forms  or  subdocuments 

i which  provide  specific  support  to  the  SOW  requirements.  Some 

I of  these  additional  subdocuments  are: 

I 

a.  The  Purchase  Request  Form. 

b.  A desired  schedule  for  SOW  task  accomplishment. 

c.  A request  for  Determinations  and  Findings  (as 

j appropriate) . 

i 

1 d.  A Technical  Evaluation  Plan. 

e.  Technical  Evaluation  Criteria. 

f,  A Consolidated  Data  Requirements  List  and  supporting 
Data  Item  Descriptions. 

• g.  A Security  Requirements  Checklist  (when  appropriate) . 

h.  A Sole  Source  Justification  (when  appropriate) . 

i.  A List  of  Qualified  Potential  Contractors. 

j.  A Synopsis  of  the  Procurement  for  the  "Commerce 
Business  Daily." 
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It  is  impossible  to  generate  a comprehensive  list  that 
would  be  applicable  to  all  R&D  procurements.  The  above  list 
is  just  a sample.  The  personnel  in  procurement  and  the 
internal  laboratory  PR  coordination  cycle  can  tell  the  project 
engineer  exactly  what  documents  must  accompany  his  SOW  in  the 
PR  package.  The  project  engineer  should  identify  and  prepare 
all  these  required  documents  prior  to  entering  the  PR  coordina 
tion  cycle  with  his  project.  It  may  preclude  delays  in  the 
procurement  cycle  that  can  be  precipitated  by  incompletely 
documented  PR  packages. 

SELECTION  OF  QUALIFIED  POTENTIAL  CONTRACTORS 

A quality  statement  of  work  would  be  meaningless  if  it 
is  not  sent  to  contractors  who  are  qualified  to  perform  the 
technical  effort  required.  The  project  engineer  must  work 
very  closely  with  his  Procurement  Contracting  Officer  in 
order  to  assure  that  all  qualified  contractors  have  been 
identified  and  that  they  will  all  be  invited  to  submit 
technical  proposals.  This  identification  should  be  completed 
well  in  advance  of  the  formal  submission  of  the  PR  package 
to  procurement,  ’’’he  reason  is  rather  obvious.  Ho  project 
engineer  would  appreciate  a last  minute  delay  in  the  pro- 
curement processing  of  h'is  PR  package  because  all  of  the 
qualified  potential  contractors  had  not  been  properly 
identified.  Consequently,  the  project  engineer  should  assist 
and  cooperate  with  the  procurement  procedures  that  enhance 
a timely  identification  of  qualified  contractors  for  his 
project. 

INSTRUCTIONS  FOR  PREPARING  TECHNICAL  PROPOSALS 

As  mentioned  earlier  in  this  chapter,  two  of  the 
elements  in  a PR  package  are  the  Technical  Evaluation  Plan 
and  the  Technical  Evaluation  Criteria.  They  serve  as  the 
basis  for  the  procurement  generated  "Instructions  for  Pre- 
paring Technical  Proposals"  which  is  sent  to  contractors  at 
the  same  time  that  the  technical  proposals  are  solicited. 

It  serves  to  guide  the  contractors  in  the  preparation  of 
responsive  technical  proposals  thereby  broadening  the  base 
for  a competitive  procurement. 

Contractors  frequently  are  given  a much  shorter  period 
of  time  to  submit  their  proposals  than  the  project  engineer 
had  to  prepare  his  SOW.  As  a result,  the  project  engineer 
should  incorporate  into  the  PR  package  enough  guidance 
concerning  Technical  Evaluation  to  allow  a contractor  to 
determine  the  imoortant  aspects  of  the  proposed  R&D  effort. 
Prospective  contractors  should  be  informed  c bout  the 
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relative  importance  of  the  technical  proposal  evaluation 
factors  that  will  be  applied  to  the  proposals.  This 
assures  that  all  potential  contractors  will  submit  and 
have  their  proposals  evaluated  on  a common  basis.  However, 
the  specific  criteria  for  the  valuation  are  not  disclosed 
to  the  prospective  contractors.  To  do  so  might  be  tanta- 
mount to  forcing  the  contractors 1 proposals  to  emphasize 
more  evaluation  criteria  adherence  and  less  creativity 
and  responsiveness  to  the  technical  requirements  of  the  SOW. 

One  concern  that  always  comes  to  mind  when  contractors 
are  preparing  proposals  is  "Just  how  important  is  it  to 
strictly  adnere  to  the  SOW  requirements  while  writing  a 
technical  proposal?"  Are  deviations  to  the  SOW  permissible 
or  will  they  prejudice  the  technical  merit  of  the  proposal? 

As  a result  one  of  two  alternatives  should  be  pursued.  If 
new  ideas  and  fresh  approaches  are  desired  in  technical 
proposals,  inform  all  potential  contractors  through  the 
PCO  that  deviations  or  alternate  proposals  will  be  considered 
if  the  contractor  can  demonstrate  that  the  government  will 
benefit  from  the  deviations.  The  second  alternative  is  to 
inform  the  prospective  contractors  to  rigidly  adhere  to  SOW 
requirements.  However,  if  this  second  alternative  is  utilized 
it  should  be  additionally  emphasized  that  a technical  proposal 
that  merely  "parrots"  the  SOW  is  not  an  acceptable  proposal. 
The  relative  importance  of  the  technical  proposal  evaluation 
factors  may  need  reiteration  if  this  alternative  is  utilized. 

One  final  point  should  be  specifically  included  in  the 
Instructions  to  the  contractor.  All  contractors  should  be 
advised  that,  while  they  are  writing  their  technical  p7.*oposals 
all  questions  concerning  the  SOW  requirements  or  any  other 
aspect  of  the  solicitation  must  be  routed  through  the  Con- 
tracting Officer.  The  project  engineer  should  answer  no 
questions  until  he  has  the  specific  authorization  of  the 
Contracting  Officer.  When  permission  has  been  granted  and 
the  answers  are  formulated,  the  information  should  be  trans- 
mitted to  all  contractors  preparing  proposals.  As  a result 
of  such  procedures,  no  contractor  gains  a competitive 
advantage  over  another  by  circumventing  the  Contracting 
Officer  and  directly  asking  the  project  engineers  for 
information. 

PREPROPOSAL  BRIEFINGS 


Official  preproposal  briefings  of  prospective  contractors 
may  be  held  when  an  R5D  project  is  too  complex  or  general  to 
allow  proper  detail  of  background  to  be  included  in  the  PR 
package  and  the  resulting  Solicitation.  Where  possible,  only 
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one  briefing  is  given  so  that  uniformity  of  information 
is  provided.  This  briefing,  however,  must  not  be  used  by 
a project  engineer  in  an  effort  to  preclude  the  writing 
of  a detailed  statement  of  work. 

A preproposal  briefing  may  be  given  whenever  any  of 
the  following  conditions  exist: 

a.  The  procurement  can  be  awarded  on  a competitive 
basis,  and  it  is  important  that  all  firms  receive  equal 
information. 

b.  A significant  savings  can  be  effected  in  technical 
manhours  by  explaining  details  of  the  procurement  on  a group 
basis. 

c.  Separate  visits  by  prospective  contractors  result 

in  recurrent  disruptions  of  an  entire  technical  group  because 
of  the  location  or  use  of  a model  or  the  limited  availability 
of  reference  materials. 

d.  Close  control  of  prospective  contractor's  visits  is 
desired  by  the  project  engineer  for  security  or  other  reasons. 

e.  Industry  has  shown  a lack  of  interest  in  this  area 
of  endeavor,  and  a concerted  effort  is  desired  to  arouse 
interest. 

f.  Laboratory  supervision  has  determined  that  it  is 
otherwise  warranted. 

The  Contracting  Officer  will  conduct  the  briefing.  A 
complete  record  of  the  briefing  will  be  made.  The  project 
engineer  will  ensure  that  the  proper  technical  personnel 
are  available  for  participation  and  that  pertinent  data  or 
models  are  available  for  presentation. 
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APPENDIX  A 


TECHNICAL  RISK  AND  THE  SELECTION  OF 
CONTRACT  TYPE 


TYPES  OF  CONTRACTS 


The  selection  of  the  proper  type  of  contract  is  an 
integral  part  of  the  R&D  procurement  process.  The  term 
"type  of  contract"  generally  conveys  three  meanings  - 
form,  end  purpose  and  compensation  arrangement. 

Type  of  contract  related  to  form.  Form  refers  to 
the  construction  of  the  contract  as  it  pertains  to  terms 
and  conditions,  for  example,  letter  contract,  definitive 
contract,  basic  agreement,  etc. 

Type  of  contract  related  to  the  end  purpose.  End 
purpose  pertains  to  the  purpose  for  which  the  contract 
is  consummated,  for  example,  an  end  purpose  might  be  to 
procure  supplies,  services,  construction,  research  and 
development,  etc. 

Type  of  contract  related  to  the  compensation 
arrangement,  for  example,  Firm  Fixed  Price,  Cost  Plus 
Fixed  Fee,  etc.  Consideration  of  the  types  of  contracts 
as  they  pertain  to  compensation  arrangements  is  the  central 
focus  of  this  appendix.  If  the  phrase  "types  of  contract" 
or  "contract  type"  reappears  in  this  appendix,  it  should 
be  understood  to  mean  type  of  contract  relating  to 
compensation  arrangement. 

The  choice  of  the  type  of  contract  can  be  a very 
simple  task  or  require  considerable  thought  depending  on  the 
situation.  In  a competitive  situation  for  a rather  simple 
well  defined  item,  the  choice  will  be  a Firm  Fixed  Price 
(FFP)  contract.  If  the  item  is  quite  complex  and  not  easily 
defined,  the  choice  will  be  something  other  than  an  FFP  con- 
tract. In  any  event,  the  "Buyer"  will  have  to  exercise 
judgment  in  the  selection  of  a type  of  contract.  Some  factors 
he  must  consider  are  the  risk  involved  in  production,  the 
clarity  of  the  specifications,  the  terms  and  conditions  of 
the  contract,  the  contractor's  competitive  posture,  etc. 
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The  selection  of  contract  type  is  a matter  of  major 
interest  to  both  the  Department  of  Defense  (DOD)  and 
industry.  As  such,  policy  pertaining  to  selection  of 
contract  type  is  in  a constant  state  of  evolution.  The 
basic  structuring  of  contract  type,  however,  remains 
unchanged.  Since  this  is  the  case,  the  Buyer  with  a 
firm  foundation  in  understanding  the  basic  structures 
of  contract  types  will  be  able  to  readily  adapt,  in  a 
fair  and  reasonable  manner,  to  meet  the  challenge  of  the 
changing  environment.  The  buyer  should  be  aware  of  a 

major  limitation  inherent  in  his  position the  fact 

that  he  deals  only  with  an  instant  contract.  Although 
the  contractor  is  motivated  by  long  run  profit  to  obtain 
his  long  range  goal  of  survival,  in  the  short  run,  he  may 
be  willing  to  sacrifice  profits  based  on  full  cost  in 
order  to  help  cover  his  variable  costs  and  a portion  of 
his  fixed  cost. 

TECHNICAL  RISK  RELATED  TO  TYPE  OF  CONTRACT 


In  order  to  realistically  choose  a type  of  contract 
that  meets  a specific  situation,  an  effective  appraisal 
of  technical  risk  must  be  undertaken.  This  analysis  of 
risk  for  a complex  system  must  include  appraisals  by  a 
team  of  technical  experts  which  will  include  personnel 
from  Engineering,  Requirements  and  Procurement.  After 
review  of  technical  risk  and  quantification  of  risk  factors 
into  dollars,  the  Buyer  will  have  an  approximation  of  the 
dollar  risk  involved.  This  will  provide  a starting  point 
for  determining  the  proper  type  of  contract. 

Figure  A-l,  Technical  Risk  Related  to  Contract  T^fpe, 
is  a visual  presentation  of  how  the  adequancy  of  the  require- 
ment definition  generally  related  to  technical  risk  and  the 
type  of  contract.  The  type  of  contract  shown  for  any  specific 
condition  is  not  necessarily  the  best  for  an  actual  situation. 
Each  case  must  stand  on  its  own.  The  essential  differences 
between  a Fixed  Price  type  of  contract  and  a Cost  Reimburse- 
ment contract  are  the  conditions,  that  is,  in  a Fixed  Price 
Contract  the  specified  product  must  be  delivered,  whereas, 
in  the  normal  Cost  Reimbursable  contract,  costs  will  be 
reimbursed  regardless  of  product  delivery  if  they  are  allocable, 
allowable,  and  reasonable.  Several  generalities  should  be 
reviewed  in  conjunction  with  Figure  A-l. 


Technical  Risk  Related  to 


WORK  STATEMENT 


a.  As  the  requirement  progresses  from  an  ill-defined 
requirement  to  a well  defined  requirement,  the  technical 
risk  will  be  reduced  from  a high  to  a low  level. 

b.  Research  and  development  contracts  generally  have 
rather  high  technical  risk  associated  with  them.  This  is 
due  to  the  factor  of  ill-defined  requirements  which  arise 
from  the  necessity  to  deal  beyond,  or  at  least  very  near 
the  upper  limits  of  the  current  technology  (often  called 
"the  state-of-the-art") . 

c.  The  types  of  contracts  generally  associated  with 
ill-defined  requirements  are  Cost  or  variations  of  Cost 
type  contracts.  As  the  requirement  becomes  better  defined, 
the  type  of  contract  transitions  from  the  Cost  type  to  the 
Fixed  Price  type  of  contract.  If  the  requirement  can  be 
adequately  defined,  an  FFP  contract  may  be  used. 

A summary  of  the  fixed  price  and  cost  types  of  contracts, 
their  applicability  and  advantages  and  disadvantages  to  the 
government  and  contractor  are  presented  in  Figures  A-2  and 
A-3 . 


Figure  A-2  - SUMMARY  OF  TYPafci  OF  CONTRACTS  - FIXED  PRICK 


Range  of  contract  types,  with  their  theoretical  advantages 

and  disadvantages 


Contract 

Type 

Application 

Advantages  to 
Government 

Disadvantages 
to  Government 

Advantages  to 
Contractor 

Disadvantages  to 
Contractor 

Firm-Fixed- 

Where  fair  and 

Shifts  total  risk 

Presolution  of 

Potential  for  higher 

Total  assumption  of 

Price 

reasonable  price  can  be 

to  contractor. 

desigu  problems 

profit. 

financial  and 

established  at  outset. 

Minisun 

Price  must  con- 

Minimus  government 

technical  risks. 

For  example,  wnere 

administration. 

tain  contin- 

control. 

Risk  of  loss  liability 

there 

Simplifies  bud- 

gencies. 

Well-defined 

for  work  in  process. 

definite  design  or 

geting. 

No  in-process 

specifications; 

Requires  vigilance  to 

performance  spec if i- 

Some  degree  of 

control  of 

better  cost 

institute  change 

cations,  realistic 
estimates,  adequate 
competition,  valid 
cost  or  pricing  data 
providing  reasonable 
price  comparisons. 

price  competit- 
ion. 

Uniformity  for  bid 
evaluation. 

Contractor  respons- 
ible for  manage- 
ment. 

Well-defined 
work  statement  and 
specifications. 

work. 

estimates. 
Les*  financial 
audit. 

claims. 

Fixed-Price  Where  market  or  labor 
with  conditions  are  unsta- 

Escalation  ble  over  extended 
production  period. 
Where  ccntigencies 
must  be  identified 
and  covered  sep- 
arately by 
escalation. 


May  result  in  Increased  Spreads  risk, 

downward  adjust-  administrative 

cents.  costs. 

Contractor  respon- 
sible for 
management. 

Reduces  contin- 
gency dollars  in 
price. 


Contains  absolute 
ceiling. 

Escalation  limited  to 
industrywide 
contingencies. 

Contingencies  within 
contractor  control 
extluded. 


Fixed-Price-Where  cost  uncertain- 
incentive  ties  exist  and  there 
vcost  only)  is  tuc  possioility  of 
cost  reduction  rn d/or 

ments  by  giving 
contractor: 

a.  a degree  of  cost 
responsibility  and 

b.  a positive  pro- 
fit incentive. 

Spreads  risk. 

Less  reason  for 
contingencies  in 
price. 

efficiency. 

Contractor  respon- 
sible for  manage- 
ment. 

No  ceiling  on 
incentive  for 
efficiency. 

Increased 
administra- 
tive co"ts. 
Must  tex^-st  to 
ceiling  price 
Complex 
negotiations. 

Potential  for 
higher  profit 
for  higher 
risk. 

Rjmurdxgooa 

management. 

Price  Ceiling 
Government  verifi- 
cation of  costs. 
Complex  negotiations, 
(kmerrment  .tends  to 
treat  as  cost  type, 
contract  controls, 
cost  principles, 
and  so  forth. 

Limits  technical 
innovation. 

Fixed-Price  A.  Prospective. 

Possibility 

Little  moti- 

Reduces  risk. 

May  include  absolute 

Redeteimvn-  For  quantity  pro- 

of  downward 

vation  for 

ceiling. 

aole  ducticn  or  services 

where  realistic 
price  cm  be 
negotiated  initi- 
all>  but  not  for 
later  period(s)  of 
performance. 

adjustment. 

cost 

reduction. 

Government  veri- 
fication of 
accounting  records. 

B.  Retroer.tive. 

Where  a fair  and 

Little  moti- 

Very  limited 

Ceiling  Price. 

reasonable  FFP  can 
not  be  negotiated 
and  the  amount 
involved  is  so 
small  or  the  time 
for  performance  so 
short  that  tne  use 
of  contract  is 
impractical. 

vation  for 
cost 

reduction. 

risk. 

More  detailed 
accounting  records. 

C-overment  verifi- 
cation of  account- 
ing records. 

Modified  fron  Exhibit  IV  entitled  Range  of  Contract  Types,  With  Their  Theoretical  Advantages  and  Disadvantages  from 
'^fajor  D00  Procurements  at  War  Witn  Reality*'  by  Hudson  B.  Drake  (January- February  1970;  Harvard  Business  Review, 
Permission  granted  by  Harvard  Business  Review  (16  November  1972)  to  modify  and  reprint. 


Figure  A- 3 - SUMMARY  OF  TYPES  OF  CONTRACTS  - COSTS 

Range  of  contract  types,  with  their  theoretical  advantages 

and  disadvantages 


Contract 

Type 

Application 

Advantages 
To  Government 

Disadvantages 
to  Government 

Advantages 
to  Contractor 

Disadvantages 
to  Contractor 

Cost 

Where  performance  is 
uncertain  and 
reasonable  cost 
estimates  impossible 

No  fee 

No  motive  to 
reduce  cost. 

Government 
partially 
responsible 
for  management 

Minimum  risk 
Assures  recovery 
of  cost 

No  fee 

Cost 

Sharing 

Where  development 
of  research  projects 
is  jointly  sponsored 
by  government  and 
contractor,  and 
there  is  a high  prob- 
ability of  ccmercial 
benefit 

No  fee 
Bears  only 
portion  of 
cost. 
Motivates 
for  cost 
reduction 

Limited  to 
certain  R5D 
cases 

Limits  competi- 
tion 

Must  show  con- 
clusive evi- 
dence of  prob- 
ability of 

Government 
participation 
in  ccmercial 
development 

Cost  share  may 
be  excessive 

ccmercial 

benefit 


Cost-Plus- 

For  development  and 

Shared  risk 

Overrun  costs 

Limited  risk 

Incentive 

test  wnen  incentive 

'totivates  for  cost 

High  adminis- 

Possibility of 
increased  fee 
Assures  recovering 
costs 

Rewards  good 
management 

Fee 

formula  can  provide 
inducement  for  effec- 
tive managiraent. 

Where  feasible,  per- 
formance incentives 
used  together  with 
cost  and  schedule 
incentives 

effectiveness 
through  bonus - 
penalty  arrange- 
ment. 

Limited  price 
contingencies 
Cost  visibility 

trative  costs 

Reduced  fee  because 
of  reduced  risks 
Absolute  limit  on 
fte 

Disallowance  of 
certain  normal 
business  costs 
Government 
engagement 


Cost -Hus-  Kucro  perfqpaauce  is  Lwyuasizus  wr- 
Fixod-Fee  uncertain  and  accu-  foraance 

’~>te  cost  estimates  objectives 

arc  impossible.  ror 
research  or  otner 
development  effort 
wnen  tne  task  or 
job  can  be  dearly 
defined,  a definite 
goal  or  target 
expressed,  and  a 
specific  end 
peoduct  desired 


um  motivation  Low  coat  and 
for  cost  technical  risk 

efficiency  Assures  recovery 
High  risk  or  cost 

Not  for  develop- 
ment of  major 
weapons  once 
exploration 
indicates  engin- 
eering develop- 
ment feasible' 

'laximua  adiinis- 
tratlvc  burden 
Finding  uncer- 
tainties 
Settlement  of 
final  costs  is 
prolonged 


Maximum  go~en*ment 
controls  and 
reporting 
Disallowance  or 
certain  normal 
busines-  costs 
Lower  fee.,  because 
of  lower  risks 


Lost-Plus-  Wiere  firm  inccn- 
Award  Foe  tlvo  objectives  for 
( .’yard  Fco  cost,  technical  and 
feature  may  management  perfor- 
bc  used  in  nance  are  not  prac- 
conjmction  tleal.  S.iould  not  uc 
witn  ot.ier  used  if  improved  level 
contract  of  work  or  acceptable 
types)  work  cannot  bo 
dofined. 


trilateral 
determination 
of  award  fee 
’totivates 
contractor's 
management  by 
reward  fer 
superior 
performance 


Administrative 

cost 

Complex 

negotiation 


Low  Risk 
Fee  increase  for 
good  performance 
Assures  recovering 
cost 


Unilateral 
determination  of 
award  fee  by 
Government 
(Disputes  clause 
does  not  apply) 
Complex 
negotiationi 


Tine  A Wnert  impossible  to 
Materials  anticipate  cost 
lauor  Hour  (tine  and  material  or 
labor  hours)  witn  any 
reasonable  degree  of 
accuracy  wnen  ux> 
contract  is  placed. 


Necessity  ror  High 

close  survcil-  administrative 

lance  provides  cost 

good  cost 
visibility 


'cry  low  risk  Costs  allowed  in 

Assured  profit  accordance  with 

mate  ASPR  Rec  XI’ 

Ceiling  Price 
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